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1.  INTRODUCTION 

1.1.  Description  of  the  Problem 

Microprocessors  constitute  a  very  high  percentage  of  today's 
large  scale  integrated  (LSI)  circuits.  The  number  of  microprocessor- 
based  digital  systems  is  expanding  rapidly.  This  has  given  rise  to  an 
acute  need  for  sound  theoretical  tools  to  develop  efficient,  thorough 
and  cost-effective  test  programs  to  detect  faults  in  microprocessors  at 
all  levels:  at  the  component  level  during  fabrication  and  before 
encapsulation,  at  the  chip  level  before  incorporating  the  microprocessor 
into  a  system,  and  at  the  system  level  in  the  field.  These  levels 
have  their  own  testing  requirements  and  constraints  on  test  development 
and  application. 

Manufacturers  of  microprocessors  are  interested  in  testing 
various  components  and  devices  on  the  microprocessor  chip  during  its 
fabrication  for  DC  parametric  behavior  (such  as  power  consumption,  noise 
sensitivity,  fanin  and  fanout  capability,  etc.)  as  well  as  dynamic 
timing  problems,  etc.  Both  manufacturers  and  users  are  interested  in 
testing  microprocessors  at  the  chip  level  for  its  correct  functional 
operation  at  the  rated  speed.  Finally,  users  and  system  designers  are 
interested  in  ensuring  that  the  microprocessor  in  the  system  (as  well 
as  the  rest  of  the  system)  is  functioning  correctly.  Classical  fault 
detection  methods  such  as  the  D-algorithm  [RBSc67]  used  for  the  chip 
and  system  level  testing  are  employed  to  detect  logical  faults  defined 
at  a  low  level  such  as  a  line  stuck-at-one  or  stuck-at-zero  [CMMe70] 
and  [BrFr76] .  These  faults  are  associated  with  lines  interconnecting 
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gates  and  flip-flops.  For  microprocessors  which  contain  thousands  of 
gates,  flip-flops  and  interconnections,  classical  methods  must  consider 
a  very  large  number  of  faults  making  test  generation  extremely 
complicated . 

Our  approach  associates  faults  with  various  functions  of  the 
microprocessor  (defined  at  a  suitably  higher  level),  such  as  the 
register  decoding  function,  instruction  decoding  and  control  function, 
data  storage  function,  etc.  We  give  some  examples  of  faults  in  micro¬ 
processors  which  we  are  interested  in  detecting. 

Example  1.1;  When  the  instruction  "Load  register  R^"  is 
executed,  register  is  loaded  instead  of  register  R^.  This  may  happen 
due  to  a  faulty  register  decoding  function.  The  instruction  "Interrupt 
enable"  correctly  enables  the  interrupt,  but  at  the  same  time  the 
accumulator  is  cleared.  This  can  be  attributed  to  a  fault  in  the  instruc¬ 
tion  decoding  and  control  function.  The  instruction  "Add  the  contents 
of  register  R^  to  the  contents  of  the  accumulator,"  is  not  correctly 
executed  for  a  few  operands  due  to  faults  in  the  arithmetic  and  logic  (ALU) 
unit.  We  associate  these  faults  with  the  data  manipulation  function. 

A  register  may  fail  to  store  certain  data  patterns.  This  fault  is 
associated  with  the  data  storage  function.  C 

Another  important  reason  motivating  our  approach  of  considering 
faults  at  a  functional  level  is  the  constraint  imposed  on  testing  micro¬ 
processors  in  a  user  environment:  the  test  programs  need  to  be  generated 
without  knowing  the  implementation  details  of  the  chip  at  the  gate  and 
flip-flop  level.  The  only  source  of  information  which  is  readily 


available  is  the  typical  user's  manual  detailing  the  instruction  set  and 
describing  the  architecture  of  the  microprocessor.  Using  this  information 
it  is  easier  to  define  the  functional  behavior  of  a  microprocessor  and 
associate  faults  with  the  functions  as  illustrated  in  Example  1.1. 

In  tnis  thesis  we  are  concerned  with  formulating  a  sound 
theoretical  foundation  for  test  program  generation  for  testing  micro¬ 
processors  in  a  user  environment,  particularly  at  the  chip  level.  We  are 
interested  only  in  generating  deterministic  tests  to  detect  permanent 
faults  which  give  rise  to  faulty  functional  behavior  as  described  in 
Example  1.1.  We  will  not  discuss  testing  issues  related  with  dynamic  timing 
problems,  faulty  DC  parametric  behavior  or  manufacturing  or  design 
processes.  For  these  aspects  readers  are  referred  to  [TEST75] .  Of  course, 
the  "solution"  that  proposes  the  execution  of  each  instruction  for  all 
possible  operands  and  in  every  possible  sequence  for  testing  microprocessors 
is  really  not  a  solution.  It  only  serves  the  purpose  of  dramatically 
pointing  out  how  difficult  the  problem  really  is. 

We  assume  that  the  external  tester  monitors  all  the  input  and 
output  pins  of  the  microprocessor.  In  particular,  the  status  pins  and 
the  data  and  address  buses  of  the  microprocessor  are  continually  checked. 
Testing  is  stopped  on  the  detection  of  any  fault,  (may  or  may  not  be  in 
real  time)  since  we  are  not  interested  in  fault  location  on  a  chip.  The 
tester  and  the  external  memory  which  contains  the  instructions  executed 
by  the  microprocessor  are  assumed  to  be  fault  free.  Various  sophisticated 
testers  which  are  commercially  available  do  satisfy  the  requirements 
mentioned  above.  In  this  thesis  will  not  discuss  the  design  and 
implementation  or  operation  of  a  tester.  For  information  on  testers 


readers  are  referred  to  [Hust74]  and  [Ande76] . 

Sophisticated  testers  available  for  testing  microprocessor 
chips  cannot  be  conveniently  used  for  testing  microprocessors  incor¬ 
porated  in  a  system  in  the  field.  Recognizing  this  difficulty  various 
schemes  such  as  self  testing  [Ball79],  [LiDo79]  and  transition  counting 
[Haye76]  have  been  proposed.  A  notable  instrument  suitable  for  field 
testing  and  diagnosis  is  the  signature  analyzer  available  from  the 
Hewlett-Packard  Company  [HPJ077].  These  techniques  are  aimed  at  the 
ability  to  test  systems  in  the  field  without  requiring  a  sophisticated 
tester;  however,  their  fault  detection  capability  principally  hinges  on 
how  thorough  the  test  programs  are,  again  emphasizing  the  need  for  good 
test  generation  procedures.  Though  the  test  generation  procedures 
proposed  in  this  thesis  assume  the  presence  of  a  sophisticated  tester, 
we  believe  that  these  procedures  can  be  used,  with  relatively  easy 
modifications,  for  generating  tests  suitable  for  field  testing.  However, 
more  research  is  required  in  this  area. 

1.2.  Thesis  Outline 

The  goal  of  the  thesis  is  to  develop  test  generation  procedures 
for  testing  microprocessors.  These  procedures  should  treat  the  micro¬ 
processor  organization  and  instruction  set  as  parameters.  This  is 
necessary  in  view  of  the  fact  that  today's  microprocessors  differ  widely 
in  their  organization,  instruction  repertoire,  addressing  modes,  data 
storage  and  manipulation  facilities,  etc. 

In  Figure  1.1  the  thesis  outline  is  schematically  illustrated. 
In  the  beginning  of  Chapter  2  we  survey  various  models  and  methods  of 
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Figure  1.1.  Illustrating  the  thesis  outline. 
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test  generation  published  in  literature.  Since  none  of  them  is  suitable 
:-r  testing  microprocessors,  we  first  develop  a  general  graph-theoretic 
-cue.  tor  microprocessors  at  the  register  transfer  level.  Any  micro- 
-sh':  tar.  be  easily  modeled  on  the  proposed  lines  using  information 
»■  1  "it  the  instruction  set  and  the  functions  performed  by  it. 

r.ttrmation  is  easily  available  in  a  typical  user's  manual.)  This 
is  to  treat  the  microprocessor  organization  and  the  instruction 
•  •'arameters  of  the  test  generation  procedures.  We  will  illustrate 
-v  to  generate  the  graph-theoretic  model  for  a  small  example  microprocessor. 

Functional  level  fault  models  capable  of  describing  faulty 
oehav-.or  at  a  higher  level  are  presented  in  Chapter  3.  These  models  are 
quite  independent  of  implementation  details  of  a  microprocessor.  We  will 
investigate  the  effects  of  these  faults  on  the  graph-theoretic  model  of  a 
microprocessor.  In  Chapter  4  we  will  present  test  generation  procedures 
to  detect  faults  in  the  fault  models  and  prove  their  fault  coverage.  The 
generation  of  the  test  sequence  will  be  illustrated  for  the  example 
microprocessor.  The  generated  test  sequences  comprise  valid  machine 
instructions  which  are  assembled  to  produce  test  patterns.  This  may  be 
contrasted  with  the  classical  methods  which  may  generate  bit  vectors  that 
do  not  correspond  to  any  instruction. 

Chapter  5  discusses  the  complexity  of  the  test  sequences  measured 
in  terms  of  the  number  of  instructions  present  in  these  sequences.  Chapter  6 
reports  on  the  feasibility  of  our  approach.  We  will  describe  our  effort  in 
generating  tests  for  a  real  microprocessor.  The  results  were  quite 
encouraging.  Finally,  in  Chapter  7,  we  summarize  the  thesis  and  suggest 
topics  for  future  research. 


2. 


A  MODEL  FOR  MICROPROCESSORS 


Any  rigorous  exercise  of  generating  tests  for  fault  detection 
in  a  digital  system  should  consist  of  three  activities: 

1.  Constructing  a  model  at  a  suitable  level  for  describing  the 
behavior  of  the  digital  system. 

2.  Developing  a  fault  model  to  define  the  scope  of  allowable 
faults  in  the  system.  A  good  fault  model  is  usually  found 
as  a  result  of  a  trade-off  between  the  need  to  account  for 
most  of  the  faults  commonly  observed  in  the  system  and  the 
need  to  be  able  to  keep  the  complexity  of  test  generation 
low,  and  the  length  of  tests  short.  The  nature  of  the  fault 
model  is  usually  influenced  by  the  model  used  to  describe  the 
system  as  illustrated  in  Section  2.1  below. 

3.  Generating  tests  to  detect  ail  the  faults  in  the  fault  model. 

Microprocessor  testing  practised  in  industry  seems  to  be  based 
on  ad  hoc  techniques  such  as  "testing"  each  instruction  for  many  operands, 
"exercising"  various  modules  in  the  microprocessor  (such  as  the  ALU,  shifter, 
registers,  indexing  hardware),  or  running  an  application  program.  A 
typical  example  based  on  such  ad  hoc  techniques  is  [ChMc76] .  A  good 
tutorial  survey  of  testing  methods  and  tools  used  in  industry  can  be  found 
in  [FeeW78] .  Other  sources  of  information  describing  testing  strategies 
practised  in  industry  are  the  digests  of  the  annual  Semiconductor  Test 
Symposiums  sponsored  by  the  IEEE  Computer  Society  [TEST75] .  These  tech¬ 
niques  are  not  based  on  a  general  model  for  microprocessors .  Moreover, 
they  do  not  consider  any  specific  fault  model.  Therefore,  the  technique 
followed  for  testing  one  microprocessor  may  be  difficult  to  extend  to 
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other  microprocessors  having  different  architectures.  It  is  also  very 
difficult  to  know  what  faults  can  or  cannot  be  detected  using  these 
techniques . 

We  now  briefly  review  various  models  used  in  the  literature  for 
describing  digital  systems.  We  will  comment  on  their  applicability  for 
modeling  microprocessors  for  the  purpose  of  test  generation,  particularly 
in  a  user  environment. 

2.1.  Review  of  Previous  Models 

At  the  lowest  level  of  the  modeling  spectrum,  models  are  based 
on  the  gate  and  flip-flop  level  description  of  a  digital  system  in  order 
to  describe  its  logic  behavior.  Most  of  the  classical  work  on  fault 
diagnosis  uses  these  models.  At  the  highest  level  of  the  spectrum, 
models  are  based  on  the  so-called  "black  box”  description  of  the  system; 
truth  tables  are  used  to  describe  a  combinational  circuit  and  state  tables 
are  employed  for  describing  a  sequential  circuit.  As  described  below,  both 
of  these  extremes  are  unsuitable  for  modeling  microprocessors  for  the 
purpose  of  generating  tests  for  them. 

2.1.1.  Gate  and  Flip-Flop  Level  Model 

The  system  is  described  by  a  logic  diagram  consisting  of  gates 
and  flip-flops.  Thus  gates  and  flip-flops  are  recognized  as  primitive 
elements.  This  model  usually  supports  low-level  fault  models  such  as  a 
line  stuck-at-one  or  stuck-at-zero  model,  which  associates  faults  with 
lines  interconnecting  gates  and  flip-flops  [CMMe70]  and  [BrFr76] .  These 
models  were  used  to  test  and  diagnose  digital  computers  designed  with 
discrete  components  and  with  a  knowledge  of  the  detailed  logic  description 
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[Mann66] .  For  an  excellent  annotated  bibliography  on  this  topic,  readers 
are  referred  to  [Scol72] . 

These  models  are  not  very  useful  for  generating  tests  for  LSI 
circuits  such  as  microprocessors  which  contain  a  very  large  number  of 
gates,  flip-flops,  and  interconnections  and  which  therefore  require  an 
enormous  amount  of  computation  to  generate  comprehensive  test  sets.  In, 
addition,  the  required  gate  and  flip-flop  level  description  is  usually  not 
available  to  microprocessor  test  designers  working  in  a  user  environment. 

2.1-2.  State  Diagram  Model 

This  model  is  based  on  the  state  diagram  description  of  the 
system,  giving  its  output  and  the  next  state  for  any  input  and  present 
state.  The  system  is  viewed  as  a  black  box  and  all  the  implementation 
details  are  ignored.  Several  test  methods  have  been  proposed  [Koha70]  based 
on  automata  identification  experiments.  Though  this  model  supports  a  very 
general  fault  model,  the  length  of  the  test  sequence  generated  grows 
exponentially  with  the  number  of  inputs  and  states.  This  restricts  the 
use  of  the  method  only  to  toy  systems  having  a  very  small  number  of  inputs 
and  states  and  rules  out  its  applicability  to  microprocessors. 

2.1.3.  Module  Level  Model 

This  model  views  a  digital  system  as  a  network  of  interconnected 
modules  such  as  the  ALU,  register  file,  multiplexers,  demultiplexers, 
shifters,  control  unit,  etc.  Thus  the  primitive  elements  are  these 
higher  level  modules  instead  of  gates  and  flip-flops. 

The  problem  is  to  generate  tests  for  the  entire  system  using 
the  available  tests  for  individual  modules.  This  problem  as  stated  above 
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is  an  extremely  difficult  and  unsolved  problem  [Powe69]  and  [BaKi76], 
though  in  [BaKi76]  methods  are  given  to  generate  tests  for  purely  combi¬ 
national  systems  with  some  hardware  modifications.  This  model  is  also 
not  very  promising  at  its  present  state  of  research  for  generating  tests 
for  microprocessors  because  microprocessors  also  contain  sequential  logic 
and  no  hardware  modification  is  possible  in  an  existing  microprocessor 
chip . 


2.1.4.  The  Robach -Saucier  Model 

In  view  of  the  difficulties  pointed  out  in  the  previous  sections, 
Robach  and  Saucier  [RoSa75]  and  [RoSa78]  proposed  the  following  model 
for  generating  tests  for  control  units  of  digital  systems.  Every  system 
can  be  decomposed  into  two  subsystems,  the  control  and  operative  parts, 
as  shown  in  Figure  2.1(a).  The  control  part  is  characterized  by  a  repre¬ 
sentation  matrix  M  as  shown  in  Figure  2.1(b).  It  has  n  rows  corresponding 

to  the  set  of  elementary  commands  (3  =  [ c^ ,c^ ,  . .  .  ,0^} ,  and  m  columns  corre¬ 
sponding  to  the  set  of  control  states  {Q^jQ^ , . . . ,Qm"} ,  such  that  m_  =  1, 

if  the  state  Q.  activates  the  command  c. ,  and  m. .  =  0  otherwise.  The 

J  i’  i] 

operative  part  can  be  considered  to  be  made  up  of  a  set  of  independent 
functional  units.  The  set  of  commands  3  is  sent  to  one  or  more  functional 
units . 

The  diagnosis  of  the  control  part  is  performed  through  the 
operative  part  which  is  assumed  fault  free.  The  system  is  capable  of 
performing  a  set  of  "algorithms."  For  these  algorithms,  the  functioning 
of  the  control  part  is  represented  by  a  flow-chart  as  shown  in  Figure  2.1(c) 


where  the  nodes  are  the  different  control  states  of  the  considered 
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(a).  A  general  model  for  a  system. 


Control  representation  for  three  algorithms  A^,  k^,  and  A 
Figure  2.1.  The  Robach-Saucier  Model. 
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algorithms,  and  the  edges  represent  the  different  possible  transitions 
between  these  states;  the  edges  are  labeled  with  the  transition  conditions 
(predicates ) . 

A  test  of  the  control  unit  consists  of  complete  identification 
of  the  states  (distinguishability  of  every  state  from  all  other  states, 
and  checking  the  commands  generated  by  each  state  through  each  functional 
unit),  and  verfication  of  sequences.  The  fault  model  allows  commands  to 
be  abnormally  activated  or  abnormally  inactive.  Thus  this  model  considers 
basic  control  commands  and  control  states  as  primitive  elements  rather 
than  gates  and  flip-flops  generating  these  commands. 

This  approach  runs  into  two  problems  when  applied  for  generating 
tests  for  microprocessors.  First,  the  required  information  about  the 
details  of  control  states,  basic  control  commands  emitted  during  a  state, 
and  flow-charts  for  algorithms  (i.e.,  each  instruction  of  the  microprocessor) 
may  not  be  available  to  a  test  designer  working  in  a  user  environment. 

This  problem  perhaps  could  be  alleviated  by  formulating  the  control  states 
and  commands  at  a  higher  level.  Even  then,  the  method  faces  a  second 
problem;  as  shown  in  Figure  2.1(a),  it  is  assumed  that  the  operands 
(denoted  by  P)  required  for  the  functional  units  are  directly  available, 
and  the  results  (denoted  by  Z')  produced  by  the  functional  units  are 
directly  observable  (possibly  with  some  time  delay).  On  the  other  hand,  in 
the  case  of  microprocessors  a  sequence  of  instructions  needs  to  be  executed, 
in  general,  to  provide  proper  operands  to  a  functional  unit  (or  to  store 
data  in  a  register)  and  to  read  out  the  result  of  an  operation  performed 
by  it  (or  to  read  out  the  contents  of  a  register).  For  example,  consider  an 
"Add"  instruction  which  adds  the  contents  of  an  accumulator  and  a 
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scratch-pad  register  and  stores  the  result  in  the  accumulator.  A  "Load 
accumulator"  instruction  is  needed  to  load  an  operand  in  the  accumulator, 
while  two  instructions  may  be  required  to  store  an  operand  in  the  scratch¬ 
pad  register:  the  first  to  load  a  general  purpose  register  and  the  second 
to  transfer  the  contents  from  the  register  to  the  scratch-pad  register. 
Similarly  the  accumulator  can  be  read  out  only  by  executing  the  "Store 
accumulator"  instruction. 

Though  the  Robach-Saucier  approach  is  a  step  in  the  right  direction 
for  testing  certain  digital  systems  where  the  assumptions  made  in  their 
model  are  valid,  it  appears  that  the  limited  observability  and  controllability 
of  internal  registers  and  logic  of  microprocessors  pose  a  very  difficult 
problem  in  extending  the  approach  to  microprocessor  testing. 

2.1.5.  The  Thatte -Abraham  Model 

A  methodology  for  test  generation  based  on  a  model  for  a 
restricted  but  "typical"  microprocessor  organization  and  instruction  set 
was  proposed  by  Thatte  and  Abraham  [ThAb78] .  The  model  considers  an 
organization  for  the  data  processing  section  of  microprocessors  shown  in 
Figure  2.2  and  allows  only  limited  but  commonly  observed  types  of  instruc¬ 
tions,  such  as  instructions  performing  information  transfers  between  the 
main  memory  and  level  1  registers,  instructions  performing  various  ALU 
operations,  instructions  performing  information  transfers  among  level  1 
registers,  between  level  1  and  2  registers,  and  among  level  2  registers. 

The  fault  model  takes  into  account  faults  associated  with 
registers,  ALU,  buses,  and  control  section  such  as  incorrect  decoding  of 
instructions,  missing  and  extraneous  control  commands,  etc.  A  drawback 


Figure  2.2.  The  Thatte -Abraham  model. 


15 


of  this  model  is  that  it  cannot  generate  tests  for  different  microprocessor 
organizations  and  instruction  sets,  i.e.,  it  fails  to  treat  the  micro¬ 
processor  architecture  as  a  parameter  of  test  generation. 

2.2.  A  New  Model  for  Microprocessors 

In  the  light  of  the  discussion  in  Sections  2.1.1  through  2.1.5, 
we  summarize  various  requirements  for  a  model  suitable  for  generating 
tests  for  microprocessors. 

1.  The  model  should  be  based  on  a  functional  description  defined 
at  a  suitably  higher  level  such  as  the  register  transfer  level.  We  will 
define  the  model  in  terms  of  data  flow  that  occurs  between  various  registers 
and  the  main  memory  during  the  execution  of  an  instruction.  This  allows 

us  to  describe  the  functional  behavior  of  a  microprocessor  by  using 
information  about  the  instruction  set  and  functions  performed  by  it. 

Since  this  information  is  readily  available  in  a  typical  user's  manual, 
this  model  is  quite  suitable,  especially  in  a  user  environment. 

2.  The  model  should  be  able  to  treat  the  microprocessor  organization 
and  instruction  set  as  parameters  of  the  test  generation  procedure,  so 
that  for  a  given  microprocessor  architecture  it  would  be  possible  to 
generate  tests.  This  feature  is  very  desirable  as  today's  microprocessor 
differ  widely  in  their  organization  and  instruction  set,  addressing  modes, 
etc.  This  trend  is  bound  to  continue  with  newly  emerging  and  powerful 
microprocessors . 

3.  The  model  should  be  able  to  support  a  fault  model  describing 
faults  in  various  functional  primitives  such  as  the  data  transfer  function, 
the  data  storage  function,  the  instruction  decoding  and  control  function,  etc. 
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allowing  us  to  describe  faulty  behavior  without  knowing  the  details  of 
their  implementation. 

For  modeling  purposes  we  partition  the  instruction  repertoire 
of  the  microprocessor  into  three  classes.  This  classification  scheme  is 
very  similar  to  that  proposed  by  Flynn  [Flyn74] . 

1.  Transfer  class  (denoted  by  class  T) : 

Instructions  of  this  class  perform  data  transfer  between  the  main 
memory  and  a  register  (on  the  microprocessor  chip),  between  an  I/O  device 
and  a  register,  between  registers,  and  between  the  main  memory  locations. 
Examples  are  "Load  accumulator,"  "Transfer  register  R^  to  register  R2," 

I/O  instructions,  etc. 

2.  Manipulation  class  (denoted  by  class  M) : 

Instructions  of  this  class  manipulate  the  data  stored  in  the  main  memory 
or  registers  by  performing  operations  like  "Shift,"  "Add,"  "Or,"  "Decrement 
"Compare"  instruction,  etc. 

3.  3ranch  class  denoted  by  class  B): 

Class  3  consists  ::  all  chose  instructions  which  do  not  belong  to  class  T 
or  M,  e  g  ,  "land:  tuna  1  and  unconditional  branches,"  "Jump  to  subroutine" 
and  "Return  from  subroutine  -i.e.,  instructions  associated  with  program 
sequencing),'  'Interrupt  enable  and  disable,"  "Mo  operation"  instruction, 
etc  . 

The  proposed  model  is  gra ph -theoretic  in  nature.  Before  defining 
the  model  formally,  we  motivate  it  by  means  of  an  example.  We  represent 
registers  of  the  microprocessor  by  labeled  nodes  and  instructions  by 
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directed  labeled  edges  where  edges  represent  data*  flow  during  the 
fetching  and  execution  of  instructions. 

Example  2.1:  Consider  a  simple  register  transfer  instruction 
1^  transferring  the  contents  of  register  R^  to  register  •  The  data 
flow  involved  during  the  fetching  and  execution  of  I  can  be  repre¬ 
sented  in  a  graph  as  shown  in  Figure  2.3.  Nodes  R^  and  R^  represent 
the  instruction  register  and  the  program  counter,  respectively. 

The  edge  from  node  R^  to  OUT  represents  the  transfer  of  address  of 
a  main  memory  location  containing  instruction  1^  from  the  program 
counter  to  the  address  register  of  the  main  memory.  This  edge  is 
labeled  ij.  The  edge  from  node  IN  to  R^  represents  the  transfer  of 

instruction  1^  from  the  main  memory  to  the  instruction  register.  This 
2 

edge  is  labeled  1^.  While  the  instruction  transfer  is  taking  place, 

the  program  counter  is  incremented.  The  self  loop  around  node  R^ 

represents  the  function  of  incrementing  the  program  counter.  This  loop 
2 

is  also  labeled  1^.  The  edge  from  node  R^  to  R£  indicates  the  transfer 

of  data  stored  in  register  R^  to  register  R^ ,  i.e.,  the  intended 

3 

function  of  the  instruction.  This  edge  is  labeled  I ^ •  Notice  that 

the  data  flow  represented  by  the  edge  labeled  I J  takes  place  before 

2 

that  represented  by  the  edges  labeled  I  which,  in  turn,  takes  place 

3 

before  that  represented  by  the  edge  labeled  1^,  and  so  on.  Thus  the 
superscripts  on  the  edge  labels  indicate  a  precedence  relation  in 
time . 


We  use  data  as  a  generic  term  referring  to  the  information  as  well 
as  its  address. 
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Example  2.1  points  out  some  improvements  that  can  lead  to  much 
more  concise  and  succinct  representation  of  an  instruction:  we  may 
represent  that  data  f?ow  which  is  involved  only  during  the  execution 
of  the  instruction  and  not  during  its  fetching.  Since  the  data  flow 
involved  during  -he  fetching  of  every  instruction  is  the  same, 
no  information  is  gained  by  representing  it  for  each  instruction. 

On  the  other  hand  the  data  flow  involved  during  the  execution  of  an 
instruction  really  characterizes  the  function  performed  by  the 
instruction.  Thus  only  the  edge  from  node  R^  to  R£  in  Figure  2.3  can 
be  used  to  represent  instruction  I ^ • 

We  now  formalize  the  model.  A  microprocessor  is  modeled 
by  a  system  graph  (S -graph).  Let  ft  *  {r^,  R^,  R^,...}  denote  the 
set  of  registers  in  the  microprocessor.  Set  ft  includes  the  so-called 
general  purpose  registers,  accumulators,  scratch-pad  registers,  on-chip 
last-in  first-out  stack,  and  the  program  counter.  It  also  includes 
index  registers,  address  buffer  register,  stack  pointer,  etc.,  i.e., 
the  registers  used  in  various  addressing  modes.  Included  also  is  the 
so-called  processor  status  word  containing  various  processor  status  bits. 
Each  register  R^  is  represented  by  a  node  (labeled  R  )  of  the  S-graph. 

In  addition  to  the  nodes  representing  registers,  we  incorporate  two  more 
nodes,  named  "IN"  and  "OUT"  in  the  S-graph,  representing  the  world 
external  to  the  microprocessor,  i.e.,  the  main  memory  and  I/O 
devices . 

Let  J  =  f  I  ^ ,  I^,  I ^ ,  -  -  - }  denote  the  set  of  instructions.  The 
execution  of  instruction  I.  causes  data  flow  among  a  set  of  registers,  and 


between  the  main  memory  (or  an  I/O  device)  and  registers  in  some 
sequence.  The  data  may  or  may  not  be  manipulated  during  the  flow.  We 
can  represent  the  data  flow  during  the  execution  of  any  instruction  I 
as  follows: 

1.  There  exists  a  labeled  directed  edge  from  node  R  to  node  R  , 

p  q 

if  data  flow  occurs  from  register  R^  to  register  (with  or  without 
manipulation)  during  the  execution  of  I  . 

2.  There  exists  a  labeled  directed  edge  from  node  IN  to  node  R^  , 
if  data  flow  occurs  from  the  main  memory  or  an  I/O  device  to  register 
R  (with  or  without  manipulation)  during  the  execution  of  I ^ . 

3.  There  exists  a  labeled  directed  edge  from  node  R^  to  node  OUT, 

if  data  flow  occurs  from  register  R^  to  the  main  memory  (or  its  address 

register)  or  an  I/O  device  (with  or  without  manipulation)  during  the 

execution  of  I . ■ 

J 

If  more  than  one  edge  is  required  to  represent  the  data  flow 
during  the  execution  of  an  instruction,  the  flow  may  occur  in  a 
specific  sequence.  The  exact  sequence  may  not  be  known  to  test  designers 
working  in  a  user  environment  because  the  sequence  depends  on  the  details 
of  implementation  of  the  microprocessor  hardware.  However,  it  is  possible 
to  deduce  the  precedence  relation  in  time  between  the  components  of  the 
data  flow  solely  on  the  basis  of  logical  data  dependence,  independent 
of  the  details  of  implementation.  We  indicate  the  precedence  relation 
by  means  of  the  labels  assigned  to  directed  edges  as  explained  below. 


Among  the  set  of  edges  representing  the  data  flow  during  the 

execution  of  instruction  I.,  two  edges  are  labeled  I^3  and  I*?,  where  p  <  q 

J  J  J 
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and  p  and  q  are  smallest  such  positive  integers,  if  and  only  if  the  data 

flow  represented  by  the  edge  labeled  1^  must  take  place  before  that 

q 

represented  by  the  edge  labeled  in  order  to  preserve  the  underlying 
logical  data  dependence.  Two  edges  are  assigned  the  same  label  I?,  if 
and  only  if  the  corresponding  data  flows  can  occur  simultaneously  given 
the  necessary  number  of  resources  such  as  buses  and  functional  units,  i.e., 
the  required  hardware  parallelism  exists.  In  the  presence  of  some 
limitation  on  hardware  resources,  the  data  flow  represented  by  these  two 
edges  may  occur  in  either  of  the  two  possible  sequences  depending  on  the 
details  of  implementation.  If  only  one  edge  is  required  to  represent  the 
data  flow  during  the  execution  of  instruction  I  ,  it  is  assigned  a  label 
1^.  It  must  be  stated  that  this  elaborate  notation  is  used  only  for  clarity 
in  illustrating  the  data  flow  sequence  and  is  not  really  necessary  to 


generate  tests. 


Example  2.2;  Figure  2.4(a)  represents  a  "Transfer"  instruction 
1^  that  transfers  the  contents  of  register  to  register  R£ •  Figure  2.4(b) 
depicts  an  "Add"  instruction  I ^  which  adds  the  contents  of  registers  R^ 
and  R^  and  stores  the  result  in  R^-  Note  that  both  edges  are  labeled  I^. 

If  two  separate  buses  are  available  to  route  the  contents  of  registers 


R^  and  R^  to  the  ALU  simultaneously,  the  data  flow  represented  by  these 
two  edges  can  take  place  in  parallel.  If  only  one  bus  is  available,  the 
contents  of  either  R^  or  R£  are  transferred  to  the  ALU  first  and  stored  in 


its  latch,  followed  by  the  transfer  of  the  contents  of  the  other,  and 
then  the  addition  takes  place.  The  actual  implementation  determines  which 
register  is  selected  first  for  data  transfer. 
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Figure  2.4(c)  shows  an  "Or"  instruction  which  forms  the  logical 
OR  of  the  contents  of  registers  and  R£  and  stores  the  result  in  •  As 
explained  above,  both  edges  are  labeled  1^ •  Figure  2.4(d)  shows  a  "Rotate 
left"  instruction  which  rotates  the  contents  of  register  R  left  by 
1  bit.  □ 

We  now  explain  how  to  represent  instructions  which  use  addressing 
modes  by  these  graph-theoretic  techniques.  A  variety  of  addressing 
modes  is  usually  available  for  instructions  for  fetching  operands  from 
the  main  memory  and  storing  results  into  the  main  memory.  Various 
examples  of  addressing  modes  are  direct,  indirect,  immediate,  indexed, 
relative,  stack,  etc.  [GsMc75] .  Each  addressing  mode  is  characterized  by 
a  sequence  of  data  transfers  between  registers  and  the  main  memory. 

Example  2.3:  Figure  2.5(a)  represents  the  "Load  register  R^" 
instruction,  1^,  using  the  so-called  implied  or  implicit  addressing 
[GsMc75]  where  the  data  to  be  loaded  is  contained  in  the  memory  location 
next  to  the  one  storing  instruction  I ^ ,  i.e.,  the  address  of  the  operand 
is  derived  by  implication.  The  edge  from  node  R^  to  OUT  represents  the 
transfer  of  the  address  of  the  operand  from  the  program  counter  (R2), 

(which  is  incremented  by  1  by  this  time  and  points  to  the  word  next  to  the 
one  storing  instruction  I  ),  to  the  main  memory  address  register,  and  the 
edge  from  IN  to  R^  represents  the  data  transfer  from  the  main  memory  to 
register  R^ .  Figure  2.5(b)  represents  the  "Stack  push"  instruction  I7  which 
pushes  the  contents  of  R^  into  the  memory  location  (top  of  the  last-in 
first-out  (LIFO)  stack  maintained  in  the  main  memory)  pointed  to  by  the 
stack-pointer  R2  arid  then  increments  the  stack  pointer.  The  edge  from 
node  R^  to  node  OUT  in  Figure  2.5(b)  represents  the  transfer  of  data 
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(to  be  pushed  on  the  stack)  from  to  the  LIFO  stack.  The  R^-OUT  edge 

represents  the  transfer  of  the  address  of  the  top  of  the  stack  from  R^ 

(stack  pointer)  to  the  address  register  of  the  main  memory.  Both  these 

edges  are  labeled  1^.  The  self  loop  around  the  node  R^  represents  the 

2 

stack  pointer  incrementing  function.  It  is  labeled  I^  because  the  stack 

pointer  must  be  incremented  only  after  the  data  is  pushed  so  that  it 

points  to  the  location  on  the  stack  where  next  data  can  be  pushed. 

Figure  2.5(c)  shows  how  to  represent  a  register  load  instruction 

1^  using  direct  addressing  [GsMc75] .  As  shown  in  Figure  2.5(c)  the  address 

of  the  location  storing  the  operand  is  fetched  from  the  address  field  of 

instruction  I^  into  the  addres.s  buffer  register  R^  (represented  by  the 

IN-Rj  edge  labeled  1^) .  This  address  is  then  sent  from  R^  to  the  address 

2 

register  of  the  main  memory  (represented  by  the  R2-OUT  edge  labeled  1^) 

and  the  operand  is  fetched  from  the  main  memory  and  loaded  into 

3 

(represented  by  the  IN-R^  edge  labeled  1^) .  The  register  load  instruction 
1^  using  indirect  addressing  mode  can  be  represented  by  incorporating  two 
more  edges  in  Figure  2.5(c)  (one  more  edge  from  node  Rj  to  OUT  and  one 
more  edge  from  node  IN  to  R^)  as  shown  in  Figure  2.5(d). 

Figure  2.5(e)  shows  the  representation  of  a  complicated  instruc¬ 
tion  I^  "Add  (R^),  ^2),"  where  the  contents  of  registers  R^  and  R2  denote 
addresses  of  operands.  The  first  operand  for  this  instruction  is  fetched 
from  the  main  memory  location  pointed  to  by  register  R^  and  stored  in  the 

data  buffer  register  R^  (accounting  for  the  R^-OUT  edge  labeled  1^  and  the 

2 

IN-R^  edge  labeled  1^).  The  second  operand  is  fetched  from  the  main 

memory  location  pointed  to  by  register  R0  and  it  is  added  to  the  contents 

3 

of  register  R^  (accounting  for  the  R2-OUT  edge  labeled  1^ ,  the  other  edge 
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•  4 

from  IN  to  R^  labeled  1^  and  the  self  loop  around  R^).  Finally  the  result 
of  the  addition  (ready  in  R^)  is  stored  in  the  main  memory  location  pointed 
to  by  register  R^  (accounting  for  the  other  edge  from  R^  to  OUT  labeled  1^ 
and  the  R^OUT  edge).  ~ 

We  now  illustrate  the  representation  of  instructions  of 

class  B- 

Example  2.4-.  Figure  2.6(a)  represents  a  "Jump"  instruction  1^. 
The  edge  from  the  node  IN  to  R^  (representing  the  program  counter) 
represents  the  transfer  of  the  jump  address  from  the  main  memory  to  the 
program  counter.  The  R^-OUT  edge  represents  the  transfer  of  the  jump 
address  from  the  program  counter  to  the  address  register  of  the  main  memory 
achieving  the  jump  in  the  program  sequencing . 

Strictly  speaking,  the  R^-OUT  edge  (indicating  the  jump  in  the 
program  sequencing)  represents  the  transfer  of  the  address  of  a  main  memory 
location  for  fetching  a  new  instruction.  Therefore  the  R^-OUT  edge  really 
represents  a  data  flow  involved  during  the  fetching  of  the  new  instruction. 
We  take  the  flexible  viewpoint  that  the  data  flow  denoted  by  R^-OUT  edge 
could  also  be  considered  involved  during  the  execution  of  the  instructions 
of  class  B  affecting  the  regular  program  sequencing.  This  viewpoint  also 
provides  a  directed  edge  from  the  node  representing  the  program  counter  to 
the  OUT  node,  avoiding  the  awkward  situation  in  which  the  OUT  node  would 
not  be  reachable  from  the  node  representing  the  program  counter. 

Figure  2.6(b)  represents  a  "Jump  to  subroutine"  instruction 
where  the  return  address  for  the  subroutine  is  stored  in  a  local  register 
called  the  subroutine  register  (denoted  by  R2).  The  program  counter  is 
represented  by  node  .  The  IN-R^  edge  represents  the  transfer  of  the 
jump  address  from  the  main  memory  to  the  program  counter,  and  the  R^-R7 


Program 

counter 


Subroutine 

register 


(a).  1^-  Jump  instruction  (b) .  I Jump  to  subroutine  instruction 


Subroutine 


(c) .  1~-  Return  from 

subroutine  if 
bit  Z  is  set 
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(d) .  1^-  Skip  if  the 
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(e).  1^-  No  o-  eration 
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Figure  2.6.  Representation  of  instructions  of  class  B. 
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edge  represents  the  transfer  ’of  the  contents  of  the  program  counter  to  the 

subroutine  register,  i.e.,  saving  the  return  address.  The  return  address 

must  be  saved  before  the  jump  address  is  transferred  from  the  main  memory 

to  the  program  counter.  The  R^-OUT  edge  represents  the  jump  in  the  program 

12  3 

sequencing.  The  labels  of  edges  I^,  ^  ^  indicate  the  precedence 

relations  in  the  data  flow. 

Instructions  causing  only  conditional  changes  in  the  program 
sequencing  can  be  suitably  represented  by  tagging  instruction  labels 
with  the  appropriate  condition  code  (predicate).  For  example,  Figure  2.6(c) 
represents  a  "Return  from  subroutine  if  bit  Z  is  set"  instruction  I^. 

If  Z  =  1,  the  contents  of  the  subroutine  register  R^ ,  are  transferred  to 
the  program  counter  R^ .  The  R^-OUT  edge  represents  the  jump  (conditional) 
in  the  program  flow. 

Figure  2.6(d)  shows  a  "Skip  if  the  accumulator  equals  zero" 
instruction  1^.  The  predicate  can  be  denoted  by  "ACC  =  0."  The  node  R^ 
represents  the  program  counter.  The  self  loop  around  node  R^  denotes  the 
conditional  skip,  i.e.,  the  program  counter  is  incremented  if  the  accumulator 
equals  zero.  Figure  2.6(e)  shows  a  "No  operation"  instruction  I,-.  The 
R^-OUT  edge  represents  the  transfer  of  the  contents  of  the  program  counter 
to  the  address  register  of  the  main  memory  to  fetch  the  next  instruction  in 
the  regular  program  sequencing. 

Those  instructions  of  class  B  which  do  not  change  the  processor 
status  word  but  only  change  the  logic  level  on  some  status  pins  such  as 
"Interrupt  enable"  instruction  are  not  represented  in  the  S-graph.  ~ 
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2.3.  An  Example  Microprocessor 

We  now  illustrate  the  generation  of  the  S-grap'n  for  a  small 
hypothetical  microprocessor.  This  example  will  also  be  used  in  Chapter  3 
to  demonstrate  the  effects  of  faults  on  the  S-graph,  and  in  Chapter  4  to 
illustrate  various  test  generation  procedures.  Figure  2.7  shows  the  block 


diagram  of  this  microprocessor.  It  has  an  accumulator  (R^),  a  general 


purpose  register  (R0 ) ,  a  scratch-oad  register  (R  ,  a  program  counter  (R, ) 
L  *  j  o 


and  a  subroutine  register  (Ry)  to  save  the  return  address  of  subroutines, 


allowing  a  single  level  of  subroutine  nesting.  A  stack  pointer  (R^)  is 


provided  which  points  to  the  top  of  a  LIFO  stack  maintained  in  main  memory. 
An  address  buffer  register  (R,.)  is  provided  to  store  the  address  of  operands 
The  ALU  is  capable  of  performing  ADD,  logical  AND,  SHIFT  and  COMPLEMENT 
operations.  The  instruction  repertoire  contains  21  instructions  which  are 
listed  in  Table  2.1.  Though  all  the  architectural  features  of  the  example 
microprocessor  may  not  be  present  in  any  real  microprocessor,  they  have 
been  carefully  chosen  to  illustrate  some  of  the  subtle  points  involved  in 
test  generation.  It  may  be  noticed  that  instructions  1^,  1^,  I^,  I.,  1^, 


ly,  Ig,  I15>  I16,  I17>  I18  and  Iig  belong  to  class  T,  instructions  1^,  1^, 


1^2  and  I-^g  constitute  class  M,  while  class  B  contains  instructions  1^,  1^, 
■*■14’  I20  and  I2T 

Example  2.5:  The  S-graph  for  the  microprocessor  shown  in 


Figure  2.7  is  drawn  in  Figure  2.3.  The  self  loops  around  R^,  labeled  l‘. 


and  I10,  represent  the  stack  oointer  incrementing  and  decrementing  functions 
io 


respectively.  The  self  loop  around  ,  labeled  1  ■  (R^  =  ^  >  represents 


the  program  counter  incrementing  function  during  the  "Skip"  instruction  I^q, 


if  the  condition  "register  R^  = 0"  is  satisfied.  All  the  other  edges  of 


Figure  2.8  are  self-explanatory. 


Figure  2.7.  The  block  diagram  of  an  example  microprocessor. 
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Table  2.1.  The  instruction  repertoire  of  the  example  microprocessor. 

I ^  -  Load  register  R^  from  the  main  memory  using  immediate  addressing. 

I7  -  Load  register  from  the  main  memory  using  immediate  addressing. 

13  -  Transfer  the  contents  of  register  R^  to  register  R? . 

1^  -  Add  the  contents  of  registers  R^  and  R7  and  store  the  results 
in  register  R^. 

I.  -  Transfer  the  contents  of  register  R^  to  register  R^ • 

I,  -  Transfer  the  contents  of  register  R.  to  register  R.,  . 

o  J  i 

» 

-  Store  register  R^  into  the  main  memory  using  implied  addressing. 
Ig  -  Store  register  R9  into  the  main  memory  using  implied  addressing. 
Ig  -  Jump  instruction. 

I10  -  Skip  if  the  contents  of  register  R^  are  zero. 

I  ^  -  Left  shift  register  R^  by  one  bit. 

1^2  "  Complement  (bit-wise)  the  contents  of  register  R^. 

1 13  -  Logical  AND  the  contents  of  registers  R^  and  R^  and  store  the 
result  in  register  R^- 

I,.  -  No  operation  instruction. 

14 

1^3  -  Load  the  stack  pointer  'v from  the  main  memory  using  immediate 
addressing . 

I ^  -  PUSH  register  R^  on  the  LIFO  stack  maintained  in  the  main  memory. 

-  Store  register  R?  into  the  main  memory  using  direct  addressing. 

I10  -  POP  the  ton  of  the  LIFO  stack  and  store  it  in  R. . 

Io  '  i 

1^^  -  Load  register  R?  from  the  main  memory  using  direct  addressing. 

I?q  -  Jump  to  subroutine  (return  address  is  saved  in  the  subroutine 
register  R^) • 

I  -  Return  from  subroutine. 
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2.4.  Definitions  and  Notation 

Some  registers  of  the  microprocessor  can  be  written  (loaded  with 
required  data)  or  read  out  (i.e.,  its  contents  can  be  stored  in  the  main 
memory  or  sent  to  an  I/O  device)  by  executing  an  explicit  instruction. 
Examples  of  such  registers  are  accumulator  and  general-purpose  registers. 

On  the  other  hand,  some  registers  cannot  be  written  or  read  out  by 
executing  any  explicit  instruction.  For  example,  the  address  buffer 
register  of  Figure  2.5(c)  can  be  written  as  well  as  "read  out"  (on  the 
address  bus)  only  implicitly  during  the  execution  of  instruction  I^- 
Similarly,  the  stack  pointer  (I^)  of  Figure  2.5(b)  can  be  read  out 
implicitly  on  the  address  bus  during  the  execution  of  instruction  •  Note 
that  in  Figure  2.8  also,  the  stack  pointer  (R^)  can  be  read  out  only 
implicitly  during  the  execution  of  instructions  1^  or  I^g,  though  it  is 
possible  to  write  it  explicitly  by  executing  instruction  I  .  The  data 
buffer  register  (R^)  of  Figure  2.5(e)  can  be  written  or  read  out  only 
implicitly.  The  subroutine  register  (R^)  in  Figure  2.8  can  be  read  out 
only  implicitly  by  executing  the  "Return  from  subroutine"  instruction  I?^. 
Finally,  the  program  counter  can  be  written  only  implicitly  during  the 
execution  of  an  instruction  of  class  B  which 'alters  the  normal  program 
sequencing. 

We  assume  that  any  register  can  be  written  (implicitly  or 
explicitly)  as  well  as  read  out  (implicitly  or  explicitly)  using  a  sequence 
of  instructions  of  class  T  or  using  an  instruction  of  class  B.  This 
assumption  can  be  easily  justified  for  current  microprocessors  [Cush77]. 

In  terms  of  the  S-graph,  there  exists  a  path  from  the  IN  node  to  every  node 
(representing  a  register)  consisting  of  edges  representing  instructions  of 
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class  T  or  class  B.  Similarly  there  exists  a  path  from  every  node  to  the 
OUT  node  consisting  of  edges  representing  instructions  of  class  T  or 
class  B. 

Transfer  mechanisms  such  as  buses  are  used  to  transfer  data 
between  registers,  functional  units,  main  memory,  and  I/O  devices  during 
the  execution  of  an  instruction.  Since  a  test  designer  working  in  a 
user  environment  may  not  know  the  details  of  implementation  of  the  transfer 
mechanisms,  or  how  they  are  shared  or  time-multiplexed  among  different 
data  transfers,  we  "map"  a  physical  transfer  mechanism  used  during  the 
execution  of  an  instruction  onto  a  set  of  logical  entities  called 
transfer  paths •  We  illustrate  how  to  perform  this  mapping  by  means  of 
Example  2.6  below.  The  set  of  transfer  paths  associated  with  instruction 
Ij  is  denoted  by  T(I^).  The  motivation  for  presenting  the  notion  of 
transfer  paths  is  to  be  able  to  develop  a  fault  model  for  the  data  transfer 
function  independent  of  the  actual  implementation  details  of  the  transfer 
mechanisms . 

Example  2.6:  With  reference  to  instruction  1^  in  Figure  2.8, 
T(I^)  contains  three  transfer  paths,  two  paths  for  transferring  the 
contents  of  and  R£  to  the  ALU  and  one  path  for  transferring  the  output 
of  the  ALU  to  R^.  T(Ig)  contains  only  one  transfer  path  for  transferring 
the  contents  of  R^  to  R^,  while  T(I^)  contains  three  transfer  paths,  one 
for  transferring  data  (which  is  actually  the  address  of  an  operand)  from 
the  main  memory  to  R^ ,  one  for  transferring  the  address  from  R,_  to  the 
address  register  of  the  main  memory,  and  the  third  one  to  transfer  data 
from  the  main  memory  to  R£  •  1(1.,^)  contains  two  transfer  paths,  one  for 

transferring  the  contents  of  the  subroutine  register  (R^)  to  the  program 
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counter,  and  the  second  one  for  transferring  the  contents  of  the  program 
counter  to  the  address  register  of  the  main  memory.  23 

The  set  of  source  registers  for  an  instruction  I ^  is 
defined  to  be  that  set  of  registers  which  provide  the  operands  for 


instruction  I ^  during  its  execution.  This  set  is  denoted  by  S(IJ. 

Similarly,  the  set  of  destination  registers  for  an  instruction  1^  is 

defined  to  be  that  set  of  registers  which  are  changed  by  instruction  I. 

during  its  execution.  This  set  is  denoted  by  D(Ij).  Extending  this 

notation  further,  SCI,,  I,  , . .  .  ,  I  )  =  S(I,)  J  S(I0)  U .  .  ,J  SCI  )■ 

L  l  n  i  l  n 

D(I^,  I2 ,  ••■,  In)  can  be  defined  analogously.  ( S  (I  j )  f  an<*  [  D  C I . ) !  denote 
the  cardinality  of  the  corresponding  sets. 

Example  2.7:  In  the  S-graph  of  Figure  2.8,  S Cly )  =  [R^} >  SCI^) 

-  Cr1.  R^,  SCIg)  =  CR3},  S(I2)  =  {IN},  SCI21)  -  {R?},  etc.  Similarly 
DCI7)  =  [OUT],  D(I4)  *  DCIU)  -  DCI12)  -  iR1} »  °(I16)  =  (r4.  out).  D(I17) 

»  [R5,  OUT},  D(I20)  =  U6,  R7,  OUT}.  |s(I4)|  -  2,  |d(I20)|  =  3.  i 

The  set  of  directed  edges  denoting  an  instruction  1^  in  the 
5-graph  is  called  its  edge  set  and  is  denoted  by  E Cl j )  -  READ  (R^)  denotes 
the  shortest  seouence  of  instructions  of  class  T  or  class  B  that  is 


necessary  to  read  out  register  R^  (implicitly  or  explicitly).  Similarly 
WRITE  (R^)  denotes  the  shortes t  sequence  of  instructions  of  class  T  or 
class  B  that  is  necessary  to  write  register  R^  (implicitly  or  explicitly). 
|E(I.)  |  ,  | READ  (R^ ) | ,  and  |wRITE  (R^)|  denote  the  cardinality  of  the 
corresponding  set  or  sequences. 


Example  2.8:  For  the  S-graph  shown  in  Figure  2.8,  READ  (R^)  =  (l7)> 
READ  (R3)  =  I6,  I7>,  READ  (R5)  =  <I17>,  READ  (R?)  =  (l2]\  etc. 

WRITE  (R1)  =  vl  1>  ,  WRITE  (R_ )  =  Cl17>,  WRITE  (R3)  =  <1  x ,  WRITE  (R  ) 

=  <I9,  I2Q).  Thus,  IREAD  (R3 ) |  =  2,  | WRITE  (R?)|  =2.  3 
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We  allow  | D (I j ) |  >  1  only  if  instruction  I ^  involves  data  transfer 
between  the  main  memory  (or  an  I/O  device)  and  registers  of  the  micro¬ 
processor  during  its  execution.  Thus  |d(I^)|  =  1  for  all  those  instructions 
which  do  not  involve  data  transfer  between  the  main  memory  and  some 
registers  during  their  execution.  We  need  not  consider  | D (I ^. )  !  >  1  in  the 
case  of  these  instructions,  because  the  results  of  instructions  of  class  M 
or  T  are  usually  not  stored  in  more  than  one  register.  This  does  not 
mean  that  J D (I ^ ) |  >  1  for  every  instruction  I ^  which  causes  data  transfer 
to  take  place  between  the  main  memory  and  registers  during  its  execution. 

Thus  we  have  constructed  a  model  based  on  the  data  flow  involved 
during  the  execution  of  an  instruction  satisfying  the  first  requirement 
given  in  Section  2.2.  The  S-graph  depends  on  the  instruction  repertoire 
and  the  functions  performed  by  it,  i.e.,  the  S-graph  reflects  the  archi¬ 
tecture  of  the  microprocessor.  As  will  be  described  in  Chapter  4,  this 
feature  makes  it  possible  to  consider  the  instruction  set  and  organization 
as  parameters  of  the  test  generation  procedures.  This  satisfies  the  second 
requirement  given  in  Section  2.2.  The  third  requirement  is  related  to  the 
development  of  a  fault  model  defined  at  functional  level.  This  is  the 
topic  of  Chapter  3. 


2.5.  Study  of  Data  Transfers  Among  Registers 

In  this  section  we  develop  a  framework  to  study  how  the  contents 
of  registers  in  the  microprocessor  change  when  a  sequence  of  instructions 
of  class  T  (called  by  the  generic  name  T  sequence)  is  executed.  Specific 
occurrences  of  the  T  sequence  are  denoted  by  symbols  3,  3^,  3^ ,  etc • 

A  T  sequence  3  is  specified  by  listing  its  component  instructions,  i.e., 


3=<I.  ,1.  ,  . . . ,  I .  > ;  I .  is  executed  first,  followed  by  I .  ,  and  so 


J1  J2 


on . 


We  denote  this  by  I .  <  I .  <  . . .  <  I .  .  An  instruction  may  occur  more 

J1  ^2  Jn 

than  once  in  a  T  sequence.  Since  we  are  considering  data  transfers 

among  registers  only,  we  concentrate  only  on  those  instructions  of  class  T 

which  transfer  data  among  registers,  and  not  between  the  main  memory  and 

registers.  Results  derived  in  this  section  will  be  used  in  Section  4.3.3 

for  generating  tests  to  detect  faults  in  the  instruction  decoding  and 

control  function,  and  for  proving  their  fault  coverage. 

Definition  2.1:  Register  is  1-step  transferrable  to 

register  R.  under  a  T  sequence  rs  -  (i .  ,1.  ,  . ..,  I.  ),  if  the  contents 

^1  J2  •'n 

of  before  the  execution  of  the  sequence  become  the  final  contents  of 
Rj  at  the  end  of  the  execution  of  the  sequence.  Such  a  register  is 
denoted  as  R^(cr).  G 


Lemma  2.1:  Given  a  T  sequence  *  (i .  ,1.  ,  . . . ,  I .  )  and 

J1  ^2  ^n 

register  R^  ,  there  exists  one  and  only  one  register  RjCo-). 

Proof :  Follows  immediately  from  Definition  2.1.  G 

Example  2.9:  Consider  a  hypothetical  S-graph  shown  in  Figure 
2.9.  Consider  the  T  sequence  cr  =  (i^,  I ^ ,  I^,  1^)  •  We  ^ave 

R6(7)  =  V  and  R0(a)  =  R3‘  □ 

If  the  T  sequence  a,  in  the  example  above,  is  executed  one 

more  time  the  contents  of  R^  (before  the  first  execution  of  the  T  sequence) 

would  become  the  final  contents  of  R^ .  This  observation  motivates  the 

next  definition. 


Definition  2 .2 :  Register  R^  is  K-step  transferrable  to 


register  R.  under  a  T  sequence  ?  =  (i .  ,  I.  ,  ...,  I.  ),  if  the  contents 
J  J1  J2  Jn 


of  R^  before  the  first  execution  of  the  sequence  become  the  final  contents 

til 

of  R^  at  the  end  of  the  K.  execution  of  the  sequence,  where  K  is  the 
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smallest  such  integer.  Such  a  register  R.  is  denoted  as  RK(o) .  r~ 

j  - 

Example  2.10:  For  the  S-graph  shown  in  Figure  2.9, 

2 

R6(cr)  =  R3  under  the  T  sequence  a  =  iIQ,  1^  1^,  I3 ,  1^,  I  >.  2 

If  we  denote  the  T-sequence  formed  by  concatenating  two 

T  sequences  and  as  cr^*  ,  then  in  the  context  of  Example  2.10, 

1  2 

R ,(a-a)  =  R, (ct)  =  R_ .  Therefore  Definition  2.2  may  appear  rather 
obi 

K  1 

contrieved  and  artificial  because  R^  (cr)  =  R  (o'  .  a . v) ,  where  the 

T  sequence  ex  •  c . a  is  formed  by  concatenating  K  copies  of  T  sequence 

c.  However,  as  mentioned  earlier,  results  derived  in  this  section  will 
be  used  in  Section  4.3.3  where  test  generation  procedures  are  given. 

Some  of  these  test  generation  procedures  involve  loops  containing  a 
T  sequence.  When  the  loop  is  to  be  executed  K  times,  it  is  easier  and 
more  natural  to  consider  the  T  sequence  being  executed  K.  times  rather 
than  a  long  sequence  formed  by  concatenating  K  copies  of  the  T  sequence 
being  executed  once . 

M  denotes  the  smallest  integer  such  that  if  any  register  is 

K-step  transferrable  to  a  given  register  R  under  the  T  sequence 

3  —  (i ,  ,  I .  ,  ....  I .  >,  then  K  s  M. 

J1  J2  Jn 

Lemma  2.2:  Given  a  T  sequence  cr  =  (i .  ,1.  ,  ...,  I.  ) 

J1  J2  Jn 

and  a  register  R^ ,  there  exists  one  and  only  one  register  Ri’(cr) ,  where 
K  *  M. 


Proof :  Follows  from  Definition  2.2. 


We  are  interested  in  finding  the  relation  between  M  and 


n  -  the  number  of  instructions  in  o  =  ;'i  .  ,  I.  ,  I,  ).  (Recall 

Jn 


]l  h 


that  I.  <  I,  <...<!..)  In  order  to  do  this  we  first  show  how  to 


J 


1 


J 


J 
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find  R  (<7)  under  a  given  T  sequence  cr.  Consider  a  set  of  instructions 

A  =  (ii  |l4  €0  and  D(I.  )  =  { R . }} -  If  set  A  is  found  to  be  empty,  then, 

Jk  Jk  Jk  J 

of  course,  r!(<t)  =  Rj  because  the  execution  of  the  T  sequence  a  does  not 

change  the  contents  of  R^ .  Moreover,  M  =  I.  On  the  other  hand,  if  set  A 

is  found  to  be  nonempty,  then  choose  Ij  €  A  such  that  there  exists  no 

JP 

other  Ij  €  A  with  I;  <  Ij  ,  i.e.,  choose  Ij  which  is  executed  latest 

Jq  p  q  p 

in  c  but  which  still  belongs  to  set  A.  Designate  the  instruction  so 

chosen  as  1^  .  Note  that  1^  is  a  unique  instruction,  and  it  is  the  last 

instruction  in  a  which  changes  the  contents  of  R^ . 

Consider  a  set  of  instructions  B,  =  {i,  |l,  £  a,  D(I.  )  =  SCI,  ), 

1  Jk  Jk  Jk  21 

and  L  <  I,  }.  If  set  B,  is  found  to  be  empty,  then  R^(^)  =  S(I.  ) 

Jk  n  1  J  *i 

because  when  1^  is  executed  the  contents  of  S(I^  )  are  the  same  as  they 

were  before  the  first  instruction  in  cr  was  executed.  (Note  that  I^  transfers 

the  contents  of  S(I»  )  to  R.,  and  no  instruction  that  occurs  after  I  a  in 

a  can  change  the  contents  of  R^ . )  On  the  other  hand,  if  set  B^  is  found 

to  be  nonempty,  then  choose  Ij  €  B1  such  that  there  exists  no  other 

jp  i 

I.  €  with  I,  <  I-  ,  i.e.,  choose  I.  which  is  executed  latest  in  a 

Jq  p  h  Jp 

but  which  still  belongs  to  set  B^ .  Designate  the  instruction  so  chosen 
as  I,  .  Note  that  I,  is  a  unique  instruction,  and  I,  <  I ,  . 

h  l2  l\ 

Now  consider  a  set  of  instructions  B»  *  [i:  |l,  €  a,  D(I.  ) 

2  Jk  Jk  Jk 

=  SCI,  ),  and  I.  <  1.  }.  If  set  B0  is  found  to  be  empty,  then 
2  Jk  2  2 

r1(<t)  =  S(I,  ).  This  is  explained  as  follows:  When  I,  is  executed  the 
J  *‘2  2 

contents  of  S(I,  )  are  the  same  as  they  were  before  the  first  instruction  in  a 
l2 

was  executed.  I,  transfers  the  contents  of  S(I,  )  to  S(I,  )  and  the  contents 
2  2  1 

of  S(I,  )  do  not  change  between  the  executions  of  I:  and  I,  .  I,  transfers 
zi  * 2  n 


the  contents  of  S(I.  )  to  R • , 
21  J 
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7  can  change  the  contents  of  R. ■  Thus  the  contents  of  S(I*  )  before  the 

J  2 

execution  of  cr  become  the  final  contents  of  R.  at  the  end  of  the  execution 

J 

of  cr.  On  the  other  hand,  if  set  B2  is  found  to  be  nonempty,  then  choose 

I.  €  such  that  there  exists  no  other  I-  €  B2 ,  with  I-  <  I,  . 

Jp  ~  Jq  -*p  Jq 

Designate  the  instruction  so  choosen  as  I,  .  Note  that  Is  is  a  unique 

j  3 

instruction,  and  I;  <  1*  . 

3  2 

This  process  of  selecting  sets  A,  B^,  B2>  and  instructions 

» 

J 

Since  1^  < 


I,  ,  I,  ,  1 .  ,  ...  can  be  continued  until  set  B.  is  found  to  be  empty. 

1  2  1 

<  ...  <  I.  <  1 j  ,  and  there  are  n  instruction  in  7,  the 
i-1  X2  1 

process  must  terminate  in  at  most  n  steDS,  i.e.,  when  set  B.  =  {i •  |l.  €  c, 

1  K  Jk 

D (I .  )  =  S(I,  ),  and  I.  <  I}  }  is  found  empty,  the  process  terminates  and 
Jk  i  Jk  i 

we  get  R.(J)  =  S(Itf  ).  Of  course,  S(I„  )  could  be  the  same  as  R-,  in 
which  case  M  =  1. 

We  call  the  sequence  of  instructions  ,...,1^)  the 

1  l-l  *1 

characteristic  sequence  associated  with  the  transfer  of  the  contents  of 
R^(a)  to  Rj ,  and  denote  it  by  o^.  Since  each  instruction  in  7^  is  a  unique 
instruction,  the  characteristic  sequence  7^  is  also  a  unique  sequence. 

Note  that  is  a  subsequence  of  •'T.  Let  the  initial  contents  of  R^(c) 

(i.e.,  the  contents  before  the  first  instruction  in  7  is  executed)  be 
denoted  by  d^-  During  the  execution  of  7,  instructions  in  =  (i^  ,  I ^  , 

...,  I.  )  form  a  "chain"  of  instructions  transferring  the  initial  contents 

1  1 

of  R.(^)  to  R.,  i.e.,  I,  transfers  data  d,  from  R.(a)  to  S(I,  ),  I, 

J  J  zi  1  J  Vl  Vl 

transfers  data  d..  from  S (1^  )  to  S(I^  ),  ...  ,  finally  transfers 

i-1  i-2  1 

data  d.  from  S(I«  )  to  R..  Concisely  we  may  say  that  during  the  execution 
1  1  J 

of  7,  each  instruction  in  transfers  data  d  where  d^  represents  the 
initial  contents  of  r|"(j)  • 
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Example  2.11:  Consider  a  hypothetical  S-graph  shown  in  Figure 
2.10.  Consider  the  T  sequence  o'  =  (ig,  I14’  h-  'll'  V  X6 ’  V  X13 ’ 
I4,  I^g,  ^10J  Ii2>  ^5^'  Note  that  instruction  I^  is  executed  twice  in 
the  sequence.  Of  course,  in  the  S-graph  it  is  represented  only  once  using 
the  edge  from  node  to  node  R^ .  In  this  example 

A  -  {Iu.  Iu)  i  •  Iui  8(1^)  -  {SjJ. 

B1  =  ^r8 ’  ’  ll2  =  X10:  “  ^R3^‘ 

B2  =  ^6’  I9’  I13^  ’  ll^  =  1 13 ’  S^i3^  =  fR4^' 

B3  *  [I3‘  V  ;  r2,  =  X4  ;  s«(  >  ■  C*3J- 

4  4 

B4  =  ^r6’  I9’  I13"  ’  Ii5  =  I13;  S<'1^5^  =  ^-R4^  ' 

B5  =  ^3^  5  1lr  =  I3  5  =  'R6;' 

0  D 

B6  *  tx2"  Xl4>  ’  -I2  >  S(I27>  '  tR7i' 

B?  -  tlj}  i  I,  -  i  SO,  >  *  Sr4!- 

8  8 

B8  '  t®> ' 


Hence  R,(a)  =  S(I,  )  =  R. .  Note  that  I-  refers  to  the  second 
1  *8  4  0 

occurrence  of  I ^  in  a,  while  1^  refers  to  its  first  occurrence.  The 
characteristic  sequence  =  (i^,  I I^,  1 13 •  I^,  I^q.  *12^  w*lic*1 

is  a  subsequence  of  J.  C 


Now  we  show  how  to  find  RV'(ct)  under  the  T  sequence  a 
(for  K  s  M) .  If  a  register  which  is  1-step  transferrable  to  Rj(cr) 
under  the  T  sequence  z  does  not  belong  to  the  set  [r  ,  Rj(cr)},  it  must  be 


r 
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2-step  transferrable  to  Rj  and  is  designated  as  R  ^  (cr) .  On  the  other  hand, 

if  it  belongs  to  the  set  f  R^  ,  R ^ ( ^) }  it  is  1-step  transferrable  to  R^ , 

allowing  us  to  conclude  that  M  =  1.  Extending  this  argument,  if  a  register 

K 

which  is  1-step  transferrable  to  R^  (3)  under  the  T  sequence  3  does  not 

i  2  y 

belong  to  the  set  [r.,  R.(a),  R.(ct),  ...,  R  (o’)},  it  must  be  (K+l)-step 

£+1 

transferrable  to  R.  and  is  designated  as  R.  (o').  On  the  other  hand, 

J  J 

12  9  Y 

if  it  belongs  to  the  set  {r^,  r|(o)  ,  R^.  (a) ,  R“(<7),  ...,  R^(c)}  it  is 

p-step  transferrable  to  R^ ,  where  1  ^  p  ^  K.  (Refer  to  Definition  2.2.) 

In  this  case  we  can  immediately  conclude  that  M  =  K. 

We  denote  the  characteristic  sequence  associated  with  the 

transfer  of  the  contents  of  R^(o)  to  R^  ^(a)  by  o. ,  for  2  ^  i  ^  M. 

J  J  i 

Concisely  we  may  say  that  during  the  execution  of  o,  each  instruction  in 
transfers  data  d^  where  d^  represents  the  initial  contents  of  R^(o), 
for  2  ^  i  ^  M.  This  discussion  leads  to  the  following  lemma. 

Lemma  2.3:  R^(a)  is  1-step  transferrable  to  R^  ^(cr),  for 

2  ^  i  ^  M.  Some  register  in  the  set  {r^  ,  R^  (cj)  ,  Rj(O'),  ...,  R^(ct)  }  is 


M 

1-step  transferrable  to  R  (cj)  . 

Definition  2.3:  Let  c.  =  \I .  ,1.  ,1.  ,  ...)  and 

1  -^a  ^b  ^c 

•r.  ■  (i .  ,1.  ,1.  ,  .  .  . )  be  two  subsequence  of  a  T  sequence 

.  4  4  Jt 

t  =  ( T  ,  I  .....  I.  ).  3.  and  3.  are  defined  to  be  disjoint  if  the 

J1  J2  Jn  1  J 


□ 


se 


ts  [a,  b,  c,  . . . .}  and  {p,  q,  r, 


1 


are  disjoint,  i.e.,  [a,  b,  c, 


^  f 


!"  p ,  q,  r,  •••}  =  2  .  If  [a,  b,  c,  .  .  .  \  ^  {  p ,  q,  r,  .  .  . ;  ^  35 ,  c\ 


and 


3.  are  not  disjoint. 
J 


Definition  2.4:  Let  3.,  ? . ,  ,  ...  be  subsequences  of  a  T 

-  L  j  K 


sequence 


Subsequences  in  the  set  :.r., 


i-  j’  -k’ 

mutually  disjoint  if  each  pair  of  subsequences  is  disjoint.  They  are 


. . ;  are  defined  to  be 
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not  mutually  disjoint  if  any  pair  of  subsequences  is  not  disjoint. 

Lemma  2.4:  A  T  sequence  a  =  (i .  ,1.  ,  . ..,  I.  /  can  be 

J1  J2  Jn 

partitioned  into  a  set  containing  at  most  n  mutually  disjoint 
subsequences  . 

Lemma  2.5:  Subsequences  in  the  set  o^,  •••»  cr  }  are 

mutually  disjoint,  where  denotes  the  characteristic  sequence 

associated  with  the  transfer  of  rI’(c)  to  R . ,  and  cr.  denotes  the  charac- 

J  J 

teristic  sequence  associated  with  the  transfer  of  (cr)  to  ^(c), 
for  2  ^  i  ^  M. 

Proof :  During  the  execution  of  cr,  each  instruction  in  7 
transfer  data  d^  where  d^  represents  the  initial  contents  of  R^(:7)  for 
1  ^  i  S  m.  Let  us  assume  the  contrary,  i.e.,  subsequences  in  the  set 

>  •••>  <?m3  are  not  mutually  disjoint.  Therefore  at  least  one  pair 
of  subsequences,  say  cr.  and  cr,  ,  must  not  be  disjoint.  In  this  case,  at 

X  K 

the  end  of  execution  of  c,  either  the  contents  of  R^  ^(7)  are  different 

k-1 

from  d. ,  or  the  contents  of  R.  (a)  are  different  from  d,  .  This  contradicts 
i  j  k 

the  assumption  that  cr^  is  the  characteristic  sequence  associated  with  the 

transfer  of  R^C")  to  R^  ^(cr),  and  ?  is  the  characteristic  sequence 
J  J  k 

k  k-1 

associated  with  the  transfer  of  R^.  (cr)  to  R^  (c)  .  Therefore  subsequences 

in  the  set  (cr  ,  - „ ,  ...,  -  }  must  be  mutaully  disjoint. 

14.  M 

Theorem  2.1:  M  s  n,  where  n  =  the  number  of  instructions  in 
the  T  sequence  c. 

Proof :  Follows  immediately  from  Lemmas  2.4  and  2.5.  — 

Coro  1 la rv  2.1:  Let  the  initial  contents  of  registers 
12  M 

R.('C'),  RT  (cr) ,  ...  R‘.  (c)  be  d  ,  d, ,  ...,  d  ,  respectively.  Then  at  the 
j  j  J  i  <-  m 

end  of  KC^  execution  (1  ^  K  s  M)  of  the  T  sequence  j,  register  R.  will 
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th 

contain  d^.  At  the  end  of  i  execution  (i  >  M)  of  the  T  sequence  a,  R. 

will  contain  some  data  belonging  to  the  set  [dn ,  d,. ,  d  }. 

12  M 

Proof :  Follows  from  Lemma  2.3.  L 


Corollary  2.2:  If  register  contains  the  same  data  d  at 
the  end  of  each  of  i  executions  of  the  T  sequence  cr  =  (i.  ,  I.  ,  ...I.  ), 


for  1  £  i  ^  n,  then  at  the  end  of  the  (n+p)*"^1  execution  of  the  T  sequence 


J 1  J2 


c,  for  p  ^  1,  R.  will  contain  the  same  data  d. 

J 

Proof :  Follows  from  Corollary  2.1,  and  M  ^  n. 

Corollary  2.3:  If  register  R^  contains  the  same  data  d  at 
the  end  of  each  of  i  executions  of  the  T  sequence  c  containing  at  most 
K-l  instructions,  for  1  ^  i  5  K-l,  then  at  the  end  of  K*"^  execution  of 


the  T  sequence  a,  R^  will  contain  the  same  data  d. 

Proof :  Follows  immediately  from  Corollary  2.2. 
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3.  FUNCTIONAL  LEVEL  FAULT  MODELS  FOR  MICROPROCESSORS 

In  this  chapter  we  present  fault  models  for  various  functions 
in  a  microprocessor  in  accordance  with  the  third  requirement  cited  in 
Section  2.2.  We  develop  fault  models  which  are  quite  independent  of  the 
implementation  details  of  the  microprocessor.  We  categorize  various 
functions  in  a  microprocessor  into  the  register  decoding  function, 
instruction  decoding  and  control  function,  data  storage  function,  data 
transfer  function,  and  data  manipulation  function.  We  will  present  a 
fault  model  for  each  of  these  functions  at  a  higher  level.  We  will, 
however,  point  out  the  underlying  fault  mechanisms  in  order  to  clarify  the 
reasons  for  choosing  the  particular  models.  We  will  also  describe  the 
effects  of  these  faults  at  the  level  of  the  gra ph-theoretic  model  for  a 
microprocessor  presented  in  Chapter  2. 

3-1.  Fault  Model  for  the  Register  Decoding  Function 

Registers  on  a  microprocessor  chip  are  typically  realized  as 
small  random-access  memories  (RAM)  [INTE75] .  They  could  also  be  realized  as 
separate  registers  interconnected  by  a  network  of  multiplexers,  demulti¬ 
plexers  and  buses.  Various  instructions  use  registers  to  fetch  operands  or 
address  of  operands  and  to  store  results  of  operations.  Register  decoding 
refers  to  the  task  of  decoding  the  "address"  of  a  register  which  may  be 
stored  as  a  specific  bit  pattern  in  the  instructions  involving  that 
register  or  which  may  be  generated  by  the  control  unit  during  the  execution 
of  the  instructions-  We  want  to  develop  a  fault  model  for  this  decoding 
function  independent  of  the  realization  of  the  decoding  mechanism. 
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The  register  decoding  function  can  be  modeled  as  a  mapping  f 

from  ft  to  ft  U  [■$),  where  $  denotes  a  null  or  nonexistent  register.  Let 

f  (R.)  »  ft  'J  denote  the  set  of  registers  which  is  the  image  of  R. 

D  1  L 

under  the  mapping  f  .  If  there  is  no  fault  in  the  register  decoding 

function  we  get  fp(R^)  =  [r^}>  for  every  €  ft.  Under  a  fault,  if 

fu (Rf )  =  { 25 } ,  whenever  register  R^  is  to  be  accessed  (while  executing  any 

instruction  which  involves  R  ),  no  register  is  accessed.  Obviously  if 

55  c  f^(R^)  then  f^CR^)  =  {*]  because  f^(R^)  =  {r^  ,  is  meaningless 

If  f  (R.)  #  then  whenever  R.  is  accessed,  all  the  registers  in  the  set 
D  l  i 

f  (R.)  are  accessed.  By  this  we  mean,  whenever  R.  is  to  be  written  with 
D  i  i 

data  d,  all  the  registers  in  f^(R^)  would  be  written  with  data  d,  and 
whenever  the  contents  of  R.  are  to  be  retrieved  or  used,  the  contents 

l 

formed  by  the  bit-wise  OR  or  AND  function  (depending  on  technology)  over 
the  registers  of  the  set  f  (R^)  will  be  retrieved.  Under  this  fault  we 
allow  f  (R^)  £  [r^I,  for  every  R^  €  ft. 

This  situation  can  be  best  illustrated  by  means  of  a  pictorial 
representation  shown  in  Figure  3.1.  In  Figure  3.1(a)  the  mapping  f^  is 
shown  under  the  condition  that  there  is  no  fault  in  the  register  decoding 
function.  Under  this  condition,  f  is  a  one-to-one  correspondence  from 
ft  to  ft.  When  there  is  a  fault  in  the  register  decoding  function  fQ  becomes 
in  general,  a  many-to-many  correspondence  from  ft  to  ft  J  {^} .  This  is 
illustrated  in  Figure  3.1(b). 

We  now  briefly  comment  on  the  fault  mechanisms  responsible  for 
faults  in  the  register  decoding  function.  Consider  a  subset  of  registers 
ft'  £  ft  which  is  realized  as  a  random-access  memory  on  the  microprocessor 
chip.  Due  to  faults  in  the  address  decoder  in  this  memory  some  registers 


in  ft'  could  be  decoded  as  some  other  registers  in  ft'  [NTAb78] .  This  can 
be  adequately  modeled  by  a  many-to-many  correspondence  from  ft'  to 
ft'  U  [0] .  Of  course,  under  this  fault  a  register  in  ft'  cannot  be  decoded 
as  some  other  register  not  in  ft' . 

In  order  to  rule  out  the  possibility  of  a  register  being 
decoded  as  another  register  R£  under  a  fault,  we  must  know  whether  R^  and 
R^  belong  to  different  random-access  memories  realized  on  the  chip,  or 
we  must  know  of  the  existence  of  some  mechanism  (realizing  R^  and  R^)  under 
which  this  fault  cannot  be  present,  i.e.,  we  need  to  know  the  implementation 
details.  Our  desire  is  to  make  the  fault  model  as  independent  as  possible 
of  the  actual  implementation.  Therefore  we  allow  f^  to  be  a  many-to-many 
correspondence  from  ft  to  ft  U  {0}  under  a  fault.  We  are  thus  considering 
the  "worst  case"  behavior  under  the  register  decoding  faults. 

Alternatively  registers  could  be  realized  as  separate  registers 
and  interconnected  with  a  network  of  multiplexers,  demultiplexers  and 
buses.  A  typical  situation  is  shown  in  Figure  3.2,  where  it  is  desired  to 
choose  one  register  from  a  subset  of  registers  ft^  =  [r^,R?  , .  .  .  ,R  '■  —  ft  for 
transferring  its  contents  to  a  register  to  be  chosen  from  another  subset 
of  registers  ft^  =  [R^+^  ,R^+2  ’  ‘  '  '  C  T*16  task  is  accomPlished  by 
using  a  k-to-1  multiplexer  for  choosing  a  source  register  from  ft^,  and  a 
l-to-(m-k)  demultiplexer  for  selecting  a  destination  register  from  ft^  • 

The  multiplexer  and  the  demultiplexer  receive  the  addresses  of  the  registers 
to  be  selected  from  the  control  unit. 

Due  to  faults  in  these  units  the  wrong  registers  may  be  chosen, 
or  more  than  one  registers  could  be  chosen.  Under  some  fault  in  the 
control  unit,  an  incorrect  register  address  could  be  sent  to  the  multiplexer 
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or  demultiplexer  resulting  into  the  selection  of  a  wrong  register.  All 
these  faults  can  be  adequately  modeled  by  a  many-to-many  correspondence 
from  ft^  to  ft^  U  [0} ,  and  another  many-to-many  correspondence  from  ft^  t0 
ft,,  !J  {0}.  In  this  particular  implementation,  a  register  in  ft  may  not  be 
decoded  as  a  register  in  5^  >  and  vice-versa.  We  avoid  all  these  implemen¬ 
tation  dependent  details  by  allowing  f  to  be  a  many-to-many  correspondence 
from  ft  to  S  U  (01 . 

At  this  point  one  may  wonder  how  a  register  used  to  store  address 
of  operands  such  as  R^  and  R^  (in  Figure  2.8),  could  be  decoded  as  a 
register  used  to  store  operands,  such  as  R^  and  R? ,  particularly  in  the 
light  of  the  fact  that  the  widths  of  registers  used  to  store  addresses 
usually  differ  from  those  used  to  store  data.  This  is  quite  likely  in  the 
following  situation. 

All  registers  are  realized  as  a  RAM  array  on  the  microprocessor 
chip.  Each  word  of  the  RAM  is  16  bits  in  width  and  can  be  used  as  a  single 
register  for  storing  addresses  which  are  16  bits  in  width.  A  single  word 
can  also  be  used  as  a  pair  of  registers  for  storing  data  which  is  8  bits 
in  width.  This  is  the  way  registers  are  implemented  on  the  INTEL  8080 
microprocessor  [INTE75] . 


We  now  illustrate  the  effects  of  faults  in  the  register  decoding 
function  at  the  level  of  the  S-graph  by  means  of  the  following  example. 

Example  3.1:  In  terms  of  the  S-graph  of  Figure  2.3, 
ft  »  Cri,R2,R3,R^,R5,R6,R7}  .  If  f  (R5)  =  [r^,  register  R1  will  play  the 
role  of  the  address  buffer  register  R^  during  the  execution  of  instructions 
I^7  and  I  .  Thus  under  1^,  R2  will  be  read  out  correctly,  but  the 
contents  of  regiscer  R^  will  be  changed  instead  of  that  of  R^ .  If 
f^CR^)  =  {r2],  when  1^  is  executed  R2  will  be  written  instead  of  R^ . 
Moreover,  I 7  will  read  out  R2  instead  of  R^.  If  f  (R2 )  =  {R^>  R3  }>  then  Ig 
will  read  out  R^  *  R^ ,  where  *  denotes  the  bit-wise  AND  or  OR  function 
over  registers  R^,  and  R^  depending  on  technology.  Similarly  when  I2  is 
executed,  both  R^  and  R^  will  be  written  instead  of  R2 • 

If  fjjCRj)  =  !>},  then  I,.  will  not  change  the  contents  of  any 
register,  and  I&  will  transfer  a  ONE*  or  a  ZERO*  to  R^  depending  on 
technology,  instead  of  the  contents  of  R^ .  If  f^CR^)  =  {0 } ,  the  "Jump  to 
subroutine"  instruction  I2q  will  correctly  execute  the  jump  in  the  program 
sequencing,  but  will  not  save  the  return  address  into  R^ .  The  fault  will 
show  up  when  the  "Return  from  subroutine"  instruction  I2^  is  executed, 
because  the  program  sequence  will  return  to  the  main  memory  location 
whose  address  is  ONE  or  ZERO  depending  on  technology,  as  a  ONE  or  a  ZERO 
will  be  loaded  into  the  program  counter  (R^)  instead  of  the  contents 
of  R?  ■ 

ONE  denotes  a  binary  vector  with  each  of  its  bits  set  to  logic  1  and 
and  having  its  width  equal  to  that  of  a  register,  i.e.,  ONE  =  (11... 1); 
similarly  ZERO  stands  for  (00... 0). 
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If  =  instruction  I^q  will  be  executed  correctly, 

i.e.,  the  jump  to  subroutine  will  occur  and  the  return  address  will  be 
correctly  saved  in  Ry,  but  now  the  correct  execution  of  will  depend 
on  whether  1^  or  1^  were  executed  within  the  subroutine.  If  they  were 
executed  in  the  subroutine,  due  to  the  fault  fQ(Rg)  =  { Ry } j  the  subroutine 
register  Ry  will  be  changed  instead  of  the  address  buffer  register  R,- , 
resulting  into  the  loss  of  the  return  address  saved  in  Ry .  Thus  will 
cause  the  program  to  branch  to  some  location  that  equals  the  address  of 
operand  used  in  the  last  instruction  I^y  or  I^g  executed  within  the 

i 

subroutine .  -1 


3.2.  Fault  Model  for  the  Instruction  Decoding  and  Control  Function 

The  instruction  decoding  mechanism  is  shown  as  a  block  diagram 
in  Figure  3.3.  Basically  it  is  a  decoder  whose  inputs  are  the  instruc¬ 
tion  opcodes  and  whose  outputs  correspond  to  the  control  signals  that 
initiate  the  execution  of  instructions.  For  each  valid  opcode,  one 
and  only  one  output  of  the  decoder  is  activated  initiating  the  execution 
of  one  and  only  one  instruction. 

Under  a  fault  in  the  instruction  decoding  and  control  function, 
the  faulty  behavior  of  the  microprocessor  can  be  specified  as  follows. 
When  instruction  I ^  is  executed  any  one  of  the  following  can  happen: 

1.  Instead  of  instruction  I.  some  other  instruction  I,  is 

J  R 

executed.  This  fault  is  denoted  by  f  (I  /I^)  • 

2.  In  addition  to  instruction  I.,  some  other  instruction  I.  is 

J  R 

also  activated.  This  fault  is  denoted  by  f(I./l.+I.  ). 

J  J  k 

3.  No  instruction  is  executed.  This  fault  is  denoted  by  f(I 
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This  fault  model  is  strongly  motivated  by  the  fact  summarized 
in  the  following  theorem. 

Theorem  3.1:  If  a  decoder  is  realized  without  any  reconvergent 
fanout  then  under  a  single  stuck-at  fault  its  behavior  can  be  formulated 
independent  of  its  implementation  details  as  follows:  for  a  given  valid 
input  to  the  decoder,  instead  of,  or  in  addition  to  the  expected  output 
some  other  output  is  activated,  or  no  output  is  activated. 

Proof :  See  the  Appendix.  I— * 

The  assumption  of  no  reconvergent  fanout  in  the  instruction 
decoding  mechanism  is  quite  reasonable  as  it  has  n  inputs  and  as  many 
as  2n  outputs.  We  would  like  to  allow  the  faulty  behavior  stated 
above  for  each  instruction  of  the  microprocessor.  However,  it  makes 
the  test  generation  procedures  extremely  complicated.  Therefore  we 
impose  two  constraints  (given  below  as  4  and  5)  on  the  decoder  behavior 
under  faults  in  the  instruction  decoding  and  control  function. 

4.  If  faults  f(Ij/l^)  or  f(I^./I^+I^)  are  present  then  instruction 
1^  will  be  correctly  executed. 

5.  If  faults  f(I./l.  ),  f(I./l.+I  )  or  f(I./<2)  are  present  then 

J  k  J  J  k  J 

faults  f(I  /l.)  or  f(I  /I  +1.)  cannot  be  present. 

q  j  q  q  j  K 

The  behavior  of  a  decoder  under  a  single  stuck-at  fault  does  not 
violate  these  constraints.  This  will  also  be  proved  in  the  Appendix.  Any 
number  of  instructions  could  be  faulty  subject  to  the  set  of  specifications 
1  through  5.  As  an  example,  under  the  fault  model,  faults  f(I  /I?), 
f (12/12+12))  f (I^/^)  can  exist  simultaneously,  so  can  £(I  /$), 

f(I^/lg),  f (I./I^+Ig) •  Thus,  this  fault  model  can  account  for  all  single 
stuck-at  faults  in  the  instruction  decoding  mechanism. 


J 
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In  practice,  some  faults  in  the  instruction  decoding  and  control 

function  such  as  f(I./I,  )  or  f(I./l.+I,  )  may  be  readily  detected  if  a 

J  k  J  J  k 

different  number  of  machine  cycles  are  needed  to  execute  instructions  I  . 

J 

and  1^,  or  different  status  signals  are  emitted  during  their  execution 
[ThAb78]  . 

We  now  illustrate  the  effects  of  faults  in  the  instruction 
decoding  function  at  the  level  of  the  S-graph  by  means  of  the  following 
example . 

Example  3.2:  In  terms  of  the  S-graph  of  Figure  2.8,  under  fault 

fC^/^Oj  register  will  not  be  written,  i.e.,  its  contents  remain  unchanged. 

If  f(I,/l,)  is  present,  then  the  contents  of  R.  will  be  transferred  to  R. 

4  b  d  I 

instead  of  the  sum  of  R.  and  R„  .  Under  f  (I-,/l-,+I0)  ,  the  contents  of 

1  i  /  /  o 

Rl  *  R^  will  be  read  out,  where  as  before,  *  indicates  the  bit-wise 

logical  OR  or  AND  function  depending  on  technology.  If  f(Ig/lg+I^) 

is  present,  the  "Jump"  instruction  1^  will  be  executed  correctly,  but  at 

the  same  time  the  contents  of  R^  will  also  be  transferred  to  R^ • 

Note  that  the  faults  in  the  instruction  decoding  and  control 

function  cannot  be  treated  as  faults  in  the  register  decoding  function. 

For  example,  f(I^/l^)  cannot  be  treated  as  being  decoded  as  R^  if  Ig  is 

executed  correctly.  Under  f(I^Q/l7^),  instead  of  the  "Skip  if  the  contents 

of  R^  are  zero"  instruction  the  "Return  from  subroutine"  instruction  is 

executed.  Under  f (I,/I,+I ,  (RESULT1)  *  (RESULT2)  will  be  transferred 

0  o  IJ 

to  R. ,  where  RESULT1  and  RESULT2  are  the  results  produced  by  I  and  I  , 

1  o  J.J 

respectively,  and  *  indicates  the  bit-wise  logical  OR  or  AND  function 
between  RESULT1  and  RESULT2 . 
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Example  3.3:  This  example  is  constructed  to  show  how  the  result 
produced  by  executing  a  program  in  the  presence  of  a  multiple  fault  in 
the  instruction  decoding  and  control  function  differs  from  the  one  produced 
by  executing  the  same  program  under  the  fault  free  condition.  A  part  of 
the  5-graph  of  a  hypothetical  microprocessor  is  shown  in  Figure  3.4(a). 

1^,  I2 ,  I^)  I^j  1^’  ^3  are  i-nst ructions  of  class  T.  Note  that  instruction 
reads  out  register  ■  We  investigate  how  the  simultaneous  existence 
of  three  faults  f (I^/l^+Ip ,  f  (I,, /I^+Ip  ,  and  ftl^/l^+I^)  affects  the  result 
produced  by  the  microprocessor  when  it  executes  the  program  given  in 
Figure  3.4(b).  Only  three  instructions  in  the  loop  are  shown.  The  loop 
control  is  given  in  terns  of  a  high  level  language  construct  (FOR  loop) 
only  for  conciseness  and  ease  of  understanding. 

Assume  that  the  initial  contents  of  registers  R^,  R^,  R_  ,  R^ 
are  ONE,  ONE,  ONE,  and  ZERO,  respectively.  Thus  under  the  fault  free 
condition,  at  the  end  of  each  of  the  n  iterations  of  the  loop,  a  ONE  is 
read  out,  independent  of  the  value  of  n. 

Under  the  presence  of  the  multiple  fault  described  above,  the 
program  would  correctly  read  out  a  ONE  at  the  end  of  each  of  the  first 
three  iterations  of  the  loop,  but  would  read  out  a  ZERO  instead  of  a  ONE 
at  the  end  of  each  iteration  after  that.  Therefore  the  program  would  not 
detect  the  fault  if  n  s  3.  C 

3.3.  Fault  Model  for  the  Data  Storage  Function 

In  this  section  a  fault  model  for  the  data  storage  function  is 
presented  which  accounts  for  the  faults  in  various  registers.  We  allow 
any  cell  of  a  register  to  be  stuck  at  0  or  1,  and  this  fault  can  occur 


A  part  of  the  S-graph  of  a  hypothetical  microprocessor 


FOR  K  «-  l  TO  n  DO 
BEGIN 


END 


The  program  considered  in  Example  3.3. 


Figure  3.4.  Illustrating  Example  3.3. 
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with  any  number  of  cells  of  any  number  of  registers.  We  now  illustrate 
the  effects  of  faults  in  the  data  storage  function  at  the  level  of  the 
S-graph  by  means  of  the  following  example. 

Example  3.4:  In  terms  of  the  S-graph  of  Figure  2.8,  suppose 
the  first  and  third  bit  of  register  are  stuck  at  1  and  0,  respectively. 
Then,  it  would  not  be  possible  to  store  any  data  vector  whose  first  and 
third  bits  are  0  and  1,  respectively,  in  register  R  ,  by  executing  any 
instruction  whose  destination  register  is  R^.  If  the  second  bit  of 
register  R^  (subroutine  register)  is  stuck  at  0,  then  it  would  not  be 
possible  to  execute  the  "Return  from  subroutine"  instruction  I^^  success¬ 
fully  if  the  return  address  has  its  second  bit  equal  to  1.  Thus  under 
a  fault  in  the  data  storage  function  some  instructions  may  not  be 
correctly  executed  for  certain  data  and  address  patterns.  □ 


3.4.  Fault  Model  for  the  Data  Transfer  Function 

In  this  section  a  fault  model  for  the  data  transfer  function 

is  presented  which  accounts  for  faults  in  various  transfer  paths,  i.e., 

buses.  Under  a  fault  in  the  data  transfer  function  for  any  instruction  I. 

J 

1.  a  line  in  a  transfer  path  in  set  T(Ij)  can  be  stuck  at  0  or  1, 

2.  two  lines  of  a  transfer  path  in  set  T(I^)  can  be  coupled,  i.e., 
they  fail  to  carry  different  logic  values.  This  can  happen  due  to 
metallization  shorts  or  capacitive  couplings  [ThAb78] . 

We  allow  any  number  of  transfer  paths  associated  with  any  number 
of  instructions  to  be  faulty  in  this  manner.  This  fault  model  is  very 
general  and  is  also  independent  of  implementation  details  of  transfer 


paths.  Even  though  physical  transfer  mechanisms  may  be  shared  between 
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transfer  paths  in  practice,  by  allowing  each  transfer  path  to  be  faulty, 
we  are  making  the  fault  model  independent  of  implementation  details. 

We  now  illustrate  the  effects  of  faults  in  the  data  transfer 
function  at  the  level  of  the  S-graph  by  means  of  the  following  example. 

Example  3.3:  Suppose  the  transfer  path  carrying  data  from  the 
node  to  the  OUT  node  (i.e.,  the  main  memory)  in  instruction  Ig  has 
its  second  line  stuck  at  0,  then  instruction  Ig  cannot  be  executed 
successfully  if  the  data  pattern  stored  in  register  has  its  second  bit 

equal  to  1.  Suppose  the  transfer  path  used  to  carry  the  result  from  the 
ALU  to  register  R^  in  instruction  I  have  its  first  and  second  line  coupled 
such  that  the  resulting  logic  value  present  on  these  two  lines  really 
is  a  logical  OR  or  AND  function  (depending  on  technology)  of  the  logic 
values  that  would  have  been  present  on  these  lines,  were  there  no  coupling. 

Under  this  fault  any  ALU  result  whose  first  and  second  bits 
differ  in  the  logic  values  will  not  be  successfully  transferred  to  R^; 
if  the  coupling  results  in  a  logical  OR  function,  the  first  and  second 
lines  of  the  transfer  path  will  both  carry  a  logic  1  when  they  are 
supposed  to  carry  a  1  and  a  0,  or  a  0  and  a  1.  Similarly  if  the  coupling 
results  in  a  logical  AND  function,  the  first  and  second  lines  of  the 
transfer  path  will  both  carry  a  logic  0  when  they  are  supposed  to  carry 
a  1  and  a  0,  or  a  0  and  a  1.  Similar  faults  could  be  present  with  the 
transfer  paths  used  to  carry  addresses.  Thus  under  a  fault  in  the  data 
transfer  function  some  instructions  cannot  be  correctly  executed  for 
certain  data  and  address  patterns.  — 
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3.5.  Fault  Model  for  the  Data  Manipulation  Function 

The  data  manipulation  function  refers  to  various  functional 
units  such  as  the  ALU,  interrupt  handling  hardware,  hardware  used  for 
incrementing  (or  decrementing)  the  program  counter,  stack  pointer  or 
index  register,  hardware  used  for  computing  the  address  of  operands  in 
various  addressing  modes  such  as  indexed  and  relative,  etc. 

A  microprocessor  is  not  a  network  of  arbitrary  interconnections 
of  these  functional  units.  Therefore  we  need  not  really  worry  about 
the  problems  involved  in  testing  a  digital  system  comprised  of  a  network  of 
such  functional  units  as  mentioned  in  Section  2.1.3.  In  fact,  recalling 
the  discussion  of  Section  2.4  any  register  of  a  microprocessor  can  be 
read  or  written  (explictily  or  implicitly;  using  a  sequence  of  instructions 
of  class  T,  or  using  an  instruction  of  class  B,  i.e.,  the  operands 
required  for  an  instruction  of  class  M  can  be  stored  in  the  necessary 
registers  (or  are  available  in  the  main  memory)  and  the  result  produced 
by  it  can  be  read  out  from  the  register  where  it  is  stored  by  using 
instructions  which  do  not  belong  to  class  M. 

We  do  not  propose  any  specific  fault  model,  per  se,  for  the  data 
manipulation  function  because  of  the  wide  variety  in  existing  designs  for 
the  ALU  and  other  functional  units  such  as  increment  or  shift  logic. 

We  will  assume  that  complete  test  sets  can  be  derived  for  the  functional 
units  for  any  given  fault  model.  The  operands  necessary  to  execute  tests 
for  a  given  functional  unit  can  be  stored  in  the  proper  registers  by 
executing  instructions  of  class  T  or  B  only,  and  they  do  not  require  the 
use  of  any  other  functional  unit.  Similarly  the  results  of  these  tests 
can  be  read  out  by  using  instructions  of  class  T  or  3  only. 
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We  allow  any  number  of  functional  units  to  be  faulty  at  one  time. 

3.6.  Fault  Model  for  Microprocessors 

We  now  propose  the  fault  model  for  microprocessors  based  on  the 
fault  models  proposed  in  Sections  3.1  through  3.5.  At  any  given  time  we 
allow  the  presence  of  any  number  of  faults  but  only  in  one  function 
described  above  (in  Sections  3.1  through  3.5).  Note  that  we  are  allowing 
a  very  general  model  for  microprocessors  (as  described  in  Chapter  2). 

In  addition,  if  we  allow  multiple  faults  in  different  functions,  the 
problem  becomes  extremely  complex.  In  [ThAb78] ,  a  restricted  model  for 
microprocessor  was  considered,  (refer  to  Section  2.5)  allowing  multiple 
faults  in  different  functions.  In  that  case  the  problem  turned  out  to  be 
very  complex  but  of  manageable  proportions. 


m 
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4.  TEST  GENERATION  PROCEDURES 

In  this  chapter  we  present  test  generation  procedures  to 
generate  tests  for  detecting  faults  covered  by  the  fault  models  presented 
in  Sections  3.1  through  3.5.  The  first  step  in  developing  test  generation 
procedures  is  to  assign  labels  to  the  nodes  and  edges  of  the  S -graph 
under  consideration  by  using  the  labeling  algorithm  given  in  Section  4.1. 
Test  generation  procedures  for  detecting  faults  in  the  register  decoding 
function,  instruction  decoding  and  control  function,  data  transfer  and 
storage  function,  and  data  manipulation  function  are  given  in  Sections  4.2, 
4.3,  4.4  and  4.5,  respectively.  The  fault  coverage  of  the  tests  is  also 
proved . 

4.1.  Algorithm  4.1:  The  Labeling  Algorithm 

This  algorithm  assigns  integer  labels  to  nodes  and  edges.  The 
label  assigned  to  a  node  representing  register  is  denoted  by  4(R  ), 
and  the  label  assigned  to  the  edge  set  E(I^)  representing  instruction  1^ 
is  denoted  by  X(I^). 

Step  1:  Assign  a  label  0  to  the  OUT  node. 

Step  2:  K  «-  0; 

WHILE  a  node  remains  unlabeled  DO 
BEGIN 

Assign  a  label  K+l  to  all  unlabeled  nodes  representing 
registers  whose  contents  can  be  transferred  (explicitly 
or  implicitly)  to  any  register  whose  node  is  labeled  K  by 
executing  a  single  instruction  of  class  T  or  B; 

K  *■  K  +  1 


END 


instruction  that  reads  out  a  register  (explicitly  or  implicitly) 


during  its  execution. 

Step  4:  If  I  is  an  instruction  whose  edge  set  has  not  been  labeled  in 
step  3  then  assign  a  label  (K+l)  to  each  edge  in  the  set  E(I^.), 
where  4 (D(I ^ ) )  =  K.  G 

Thus  the  labeling  algorithm  first  assigns  an  integer  label  to 
each  node  of  the  S-graph.  This  label  (which  is  equal  to  | READ  (R^) I 
as  will  be  shown  in  Lemma  4.1)  indicates  the  shortest  "distance"  of  that 
node  to  the  OUT  node,  i.e.,  the  minimum  number  of  instructions  of  class 
T  or  B  that  need  to  be  executed  to  read  out  (explicitly  or  implicitly) 
the  contents  of  the  register  being  represented  by  that  node.  After 
assigning  labels  to  the  nodes  of  the  S-graph,  the  labeling  algorithm 
assigns  labels  to  the  edges  representing  instructions.  In  step  4,  each 
edge  in  the  set  E(I^)  representing  instruction  1^  is  assigned  a  label 
K+l,  if  the  destination  register  of  I ^  was  assigned  a  label  K  in  step  1 
or  2.  Note  that  in  step  4,  the  edge  sets  of  only  those  instructions  are 
labeled  which  do  not  cause  data  transfers  from  registers  of  the  micro¬ 
processor  to  the  main  memory  or  an  I/O  device  during  their  execution. 

For  such  an  instruction  1^,  | D (I ^ ) I  =  (Recall  the  discussion 
in  Section  2.4.) 

On  the  other  hand,  the  destination  set  D(I^)  of  an  instruction 
1^  that  reads  out  (explicitly  or  implicitly)  a  register  during  its 
execution  may  contain  more  than  one  register.  Since  the  nodes  representing 
these  registers  may  have  different  labels,  step  4  cannot  be  applied  in  this 
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case.  In  this  case  we  -:cc  step  3  to  assign  a  label  1  to  each  edge  in  the 
set  E(Ij).  The  choice  of  the  label  may  be  explained  by  the  fact  that  in 
this  case  the  OUT  node  has  to  be  a  member  of  the  set  D(Ij),  and  step  1 
assigns  a  label  0  to  the  OUT  node. 

For  concise  description,  we  will  use  the  phrase  "register  with 
label  K,"  if  the  node  representing  register  is  labeled  K.  Similarly 

we  will  use  the  phrase  "instruction  I ^  with  label  K,"  if  the  edge  set  E(Ij) 
representing  instruction  I  is  labeled  K.  The  phrase  "Execute  READ  (R^)" 
means  execute  instructions  in  the  READ  (R^)  sequence;  the  phrase  "Execute 
WRITE  (R.)"  can  be  interpreted  in  a  similar  fashion. 

Lemma  4.1:  a)  If  X(R.)  =  K,  | READ  (R.)|  =  K.  b)  If  £(I^)  =  1, 
1^  reads  out  (explicitly  or  implicitly)  a  register  with  label  1. 

Proof :  a)  Nodes  are  labeled  in  step  2  of  the  labeling 
algorithm.  A  node  is  labeled  1  if  the  register  represented  by  it  can  be 
read  out  (explicitly  or  implicitly)  by  executing  a  single  instruction  of 
class  T  or  B.  A  node  is  labeled  2  if  the  contents  of  the  register 
represented  by  it  can  be  transferred  to  a  register  whose  node  is  labeled  1 
by  executing  a  single  instruction  of  class  T  or  B,  and  the  former  register 
(whose  node  is  labeled  2)  cannot  be  read  out  by  executing  a  single 
instruction  of  class  I  or  B.  Thus  a  register  R^  whose  node  is  labeled  2 
can  be  read  out  by  executing  a  sequence  of  instructions  of  class  T  or  B 
containing  two  instructions  and  no  shorter  sequence  exists  to  read  it  out. 


Therefore  | READ  (R^) |  =  2.  (Recall  the  definition  of  READ  (R^)  in  Section 
2.4.)  Extending  the  argument  in  this  fashion  it  can  be  easily  proved  that 


a  register  R^  whose  node  is  labeled  K  can  be  read  out  by  executing  a 
sequence  of  instructions  of  class  T  or  B  containing  K  instructions  and 


no  shorter  sequence  exists  to  read  it  out.  Therefore  |rEAD  (R^) |  =  K. 

(b)  If  -Z(Ij)  =  1,  Ij  must  have  been  labeled  in  step  3  of  the  labeling 

algorithm,  and  it  reads  out  a  register  (explicitly  or  implicitly)  during 

its  execution.  Therefore  this  register  must  have  been  labeled  1  in 

step  2 .  □ 

We  now  comment  on  the  significance  of  the  labels  assigned  by 

the  labeling  algorithm.  For  each  register  R^,  2(R^)  indicates  the  minimum 

number  of  instructions  of  class  T  or  B  needed  to  read  out  R. .  Therefore 

i 

2(R^)  can  be  thought  of  as  an  "observability  index"  for  register  R  . 

2(Ij)  has  a  similar  connotation.  If  l{ I.)  a  2,  2(1.)  -  1  indicates 
the  minimum  number  of  instructions  of  class  T  or  B  needed  to  read  out 
register  D(I^).  If  2(1^)  =  1,  instruction  I ^  reads  out  some  register  with 
label  1;  thus  the  effects  of  execution  of  instruction  I  are  directly 
observable  at  the  externa,  pins  of  the  microprocessor  if  2(1^)  =  1. 

Various  test  generation  procedures  to  be  presented  in  the  following 
sections  of  this  chapter  generate  tests  in  such  a  way  that  the  knowledge 
gained  from  the  correct  execution  of  tests  used  to  check  the  decoding  of 
registers  and  instructions  with  lower  labels  is  utilized  in  generating 
tests  to  check  the  decoding  of  registers  and  instructions  with  higher 
labels.  Thus  the  fact  that  a  register  with  a  given  label  can  be  correctly 
"observed"  is  used  to  generate  suitable  tests  for  correctly  observing 
registers  with  higher  labels.  Recall  that  a  register  with  a  lower  label 
implies  that  it  has  better  observability  than  the  one  with  a  higher  label. 

These  test  generation  procedures  may  generate  instructions  with 
higher  labels  to  set  up  proper  operands  in  various  registers  while 
"checking  out"  instructions  with  lower  labels.  Since,  as  described  above, 
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the  instructions  with  higher  labels  are  not  checked  out  yet,  they  may  not 
be  able  to  set  up  the  required  operands  successfully.  This  imposes  the 
basic  requirement  on  the  test  generation  procedure:  the  tests  must  be 
able  to  check  for  proper  execution  of  every  instruction  using  other 
potentially  faulty  instructions;  otherwise  certain  faults  may  mask  each 
other  and  never  be  detected.  This  point  will  be  illustrated  by  means  of 
examples  in  Sections  4.2  and  4.3. 

Since  each  instruction  is  checked  for  its  proper  execution 
using  other  potentially  faulty  instructions,  it  is  not  necessary  to  devise 
some  labeling  scheme  that  assigns  labels  to  registers  indicating  their 
"distance"  from  the  IN  node  which  can  signify  their  "controllability  index." 
The  test  generation  procedures  take  into  consideration  the  presence  of 
faulty  instructions  (which  may  fail  to  store  required  operands  in  registers, 
i.e.,  fail  to  control  the  registers  correctly)  to  be  used  in  checking  out 
other  instructions. 

Recall  (Example  2.4)  that  those  instructions  of  class  B  which 
only  change  the  logic  level  on  some  status  pins  of  the  microprocessor 
(e.g.  "Interrupt  enable")  are  not  represented  in  the  S-graph.  Therefore, 


they  are  not  labeled  by  the  labeling  algorithm.  We  assign  2(1^)  =  1  for 
every  instruction  I.  of  class  B  which  is  not  represented  in  the  S-graph. 


This  assignment  can  be  justified  as  follows:  the  effects  of  these 


instructions  of  class  B  are  directly  observable  at  the  external  pins  of  the 


microprocessor.  Since  the  instructions  which  read  out  registers  are 


labeled  1  by  the  labeling  algorithm,  it  makes  sense  to  assign  label  1  to 


these  instructions  of  class  B. 
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Lemma  4.2:  All  instructions  of  class  B  are  assigned  label  1. 

Proof :  Those  instructions  of  class  B  which  are  represented  in 
the  S-graph  implicitly  read  out  the  program  counter  or  a  register 
containing  the  address  of  an  instruction.  These  instructions  are  assigned 
label  1  in  step  3  of  the  labeling  algorithm.  All  the  other  instructions 
of  class  B  (which  are  not  represented  in  the  S-graph)  are  also  assigned 
label  1  as  explained  above.  i~j 

Recall  that  instructions  with  label  1  have  the  highest 
observability.  Instruction.'  jf  class  B  enjoy  the  highest  observability. 

Example  4.1:  The  labeling  algorithm  will  assign  the  following 
labels  to  the  nodes  and  edges  of  the  S-graph  in  Figure  2.8. 

Step  1:  l (OUT)  *  0. 

Step  2:  f(R:)  -  *(R2)  *  2(R4)  =  /(Rj)  =  2(Rg)  =  2(Ry)  -  1,  i(R3>  =  2. 

Step  3:  i(I7)  -  l  (Ig)  =  2(I9)  «.2(I10>  =  2(1^)  -  2(I16)  -  i(I17)  =  *(1^)  = 

-  i(i19)  -  i(i20)  =  2(i21)  =  i. 

Step  4:  2(IX)  =  2(1,)  =  2(I3)  =  2(I4>  =  2(ig)  =  i(Iu)  =  i(I12)  =  2(1^) 

=  f(I15)  -  2,  2( I5)  =  3. 

The  contents  of  the  program  counter  (R^ )  are  read  out  (implicitly) 
on  the  address  bus  during  the  fetching  of  every  instruction,  therefore 
2(R,)  *  1.  The  contents  of  the  subroutine  register  (R_)  are  implicitly 
read  out  on  the  address  bus  (by  routing  the  contents  through  the  program 
counter),  hence  l( Ry)  *  1.  Note  that  2(1^)  =  2(I7)  =  2,  because  I ^  and 
both  use  immediate  addressing  (Refer  to  Table  2.1.),  and  i D (I ^ ) |  *  |d(I?)|  = 
All  other  labeLs  are  self  explanatory.  ~ 
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4.2.  Test  Generation  Procedure  for  Detecting  Faults  in  the  Register 
Decoding  Function 

The  tests  generated  using  the  procedure  guarantee  that 
the  register  decoding  function  denoted  by  the  mapping  f  is  a  one-to-one 
correspondence  from  ft  to  ft. 

This  procedure  uses  two  data  structures,  a  queue  of  registers 
and  a  set  of  registers  which  are  named  Q  and  A  respectively.  The  queue  Q 
is  initialized  with  all  the  registers  such  that  a  register  R^  lies  ahead 
of  another  register  in  the  queue,  if  and  only  if,  l  (R^)  £  £(R^.).  The 
set  A  is  initialized  to  be  empty.  In  each  iteration  of  the  test  generation 
procedure,  set  A  is  progressively  augmented  by  removing  the  register 
lying  in  the  front  of  the  queue  Q  and  including  it  in  set  A;  now  the 
register  which  was  second  in  the  queue  before  the  augmentation  of  set  A 
lies  in  the  front  of  the  queue,  i.e.,  the  queue  is  updated.  The  tests 
generated  so  far  will  assure  that  at  any  given  stage,  registers  in  set  A 
have  disjoint  image  sets  under  mapping  f  .  The  procedure  terminates  when 
set  A  contains  all  the  registers  that  were  initially  in  the  queue  and  the 
queue  gets  empty.  At  this  stage,  the  generated  tests  will  guarantee  that 
all  the  registers  have  disjoint  image  sets  under  mapping  f^,  establishing 
that  fQ  is  a  one-to-one  correspondence.  Recalling  the  discussion  in 
Section  4.1,  the  procedure  utilizes  the  knowledge  gained  from  the  correct 
execution  of  tests  used  to  check  decoding  of  registers  with  lower  labels 
to  generate  tests  to  check  decoding  of  registers  with  higher  labels. 

ONE  and  ZERO  will  be  frequently  used  as  operands  or  addresses 
of  operands  in  various  test  procedures.  This  choice  is  arbitrary.  We 
could  have  used  (1010... 10)  and  its  bit-wise  complement  (0101, . .01)  as 
operands  or  addresses  of  operands  instead. 
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Procedure  4.1  given  below  generates  tests  for  detecting  faults 
in  the  register  decoding  function.  Note  that  the  test  instructions  are 
generated  only  in  steps  3(a),  (b),  and  (c);  other  steps  perform  bookkeeping 
tasks . 


Procedure  4.1:  Procedure  to  generate  tests  for  detecting  faults 
in  the  register  decoding  function 

Step  1:  Initialize  the  queue  Q  with  all  the  registers  such  that 
register  IL  lies  ahead  of  register  R  ^ ,  if  and  only  if, 

Z (R^)  5  Z (r^ ) ;  Initialize  the  set  A  as  empty. 

Step  2 :  A  *-  register  at  the  front  of  Q;  Update  Q. 


Step  3:  REPEAT 

a)  Generate  instructions  to  write  each  register  R^  of  set  A 
with  data  ONE,  and  the  register  at  the  front  of  Q 

(if  there  is  one)  with  data  ZERO.  (The  instructions  of 
the  corresponding  WRITE  (R. )  sequences  need  to  be  generated.) 

b)  Generate  instructions  to  read  out  each  register  R^ 
of  set  A,  such  that  register  R  will  be  read  before 
register  R  ,  if  and  only  if,  2(R^)  5  Z  (R^ ) .  (The  instructions 
of  the  corresponding  READ  (R^)  sequences  need  to  be  generated.) 

c)  Generate  instructions  to  read  out  the  register  R^  at  the 
front  of  Q  (if  there  is  one).  (The  instructions  of  the 
READ  (Rj)  sequence  need  to  be  generated.) 

d)  A  *-  A  U  (Register  at  the  front  of  Q]. 

e)  Update  Q. 

UNTIL  Q  =  empty. 


Step  4:  Repeat  steps  1,  2,  and  3  with  complementary  data. 
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Procedure  4.1  describes  the  test  generation  procedure  at  a  higher 
level.  There  are  many  subtle  points  involved  in  the  execution  details 
of  this  procedure,  particularly  if  some  registers  can  be  written  or  read 
out  only  implicitly.  These  points  can  be  best  illustrated  by  giving 
an  example.  We  show  how  to  apply  this  algorithm  to  generate  the  tests 
for  the  S-graph  of  Figure  2.8  in  the  following  example  accompanied 
with  the  explanatory  comments . 

Example  4.2:  Generation  of  tests  for  detecting  faults  in  the 
register  decoding  function  for  the  S-graph  of  Figure  2.8. 

Step  1:  Q  R^R^R^R^RyR^ .  A  *■  0 

Step  2:  A  *-  [r^;  Q  «-  R^R^R^ 

Step  3: 

Iteration  1 


a) 

1^  with  operand  ONE; 

I^  with  operand  ZERO 

b) 

1^;  /Expected  output 

data  =  ONE/ 

c) 

IQ;  /Expected  output 

O 

data  =  ZERO/ 

d) 

A  *-  [R1S  R2} 

e) 

Q  «-  R4R5R6R7R3 

Iteration  2 

a) 

1^  with  operand  ONE; 

1 2  with  o pe rand  ONE ; 

I  with  operand  ZERO;  /stack  pointer  (R^ )  is 
written  with  a  ZERO / 

b)  1^;  I8;  /R^  and  R3  are  read  out;  expected  output  data  =  ONE/ 

c)  I ^ ;  /stack  pointer  is  implicitly  "read  out"  on  the  address 


bus;  expected  output  "data"  =  ZERO / 
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d)  A  <-  {r^  R2,  R4] 

e)  Q  <-  R5R5R7R3 

Iteration  3 

a)  1^  with  operand  ONE;  I2  with  operand  ONE; 

1^  with  operand  ONE;  /R^,  ^  j  stack  pointer  (R^)  are 
written  with  data  ONE/ 

1^  with  address  of  the  operand  ZERO;  /R_  is  written 
implicitly  with  "data"  ZERO/ 

b)  I_;  Ia;  I,.;  /R.  and  R-  are  explicitly  read  out  while 

7  o  1.0  1  - 

the  stack  pointer  (R^)  is  implicitly  read  out/ 

c)  1^^  with  the  address  of  operand  ZERO;  /R^,-  is  implicitly 
read  out  on  the  address  bus  with  expected  output 
"data"  *  ZERO/ 

d)  A  *-  CR1,  14,  R4,  R5} 

e)  Q  *-  Rg,  R^,  R^ 

Iteration  4 

a)  1^  with  operand  ONE;  I  with  operand  ONE; 

I  with  operand  ONE;  /R^,  R? ,  stuck  pointer  (R4)  are 
written  with  data  ONE/ 

I ^  with  the  address  of  operand  ONE;  /R^  is  written 
implicitly  with  "data"  ONE/ 

I  with  jump  address  =  LOC  1;  /program  counter  is 
written  implictily  with  data  =  LOC  1.  LOC  1  is  chosen 


different  from  ONE/ 


b,c)  LOC  1:  I ^ is  scored  in  location  LOC  1.  When  this 
instruction  is  fetched,  the  program  counter  is 
implicitly  read  out  on  the  address  bus;  expected 
output  "data"  =  LOC  1  #  ONE.  R^  is  explicitly 
read  out  as  I y  is  executed/ 

I  g ;  1^;  I^-j  with  the  address  of  operand  ONE;  /R2  is 
explicitly  read  out.  R^  and  R  are  implicitly  read  out/ 

d)  A  <-  {R1>  R2,  R4>  R5,  R61 

e)  Q  «-  R7,  R3 


Iteration  5 

a)  with  operand  ONE;  I2  with  operand  ONE; 

1^  with  operand  ONE;  /R^,  R2 ,  stack  pointer  (R^)  are 
written  with  data  ONE/ 

I^7  with  the  address  of  operand  ONE;  /R,.  is  written 
implicitly  with  "data"  ONE/ 

Ig  with  jump  address  -  LOC  2;  /program  counter  is  written 
implicitly  with  data  =  LOC  2/ 


LOC  2:  I  q  with  jump  address  =  LOC  3;  /Note  that  I  is 

the  "Jump  to  subroutine"  instruction,  hence 

program  counter  (now  containing  LOC  2  +  1)  is  saved 

in  the  subroutine  register  (Ry),  and  a  new  jump 

address  =  LOC  3  is  loaded  into  the  program  counter. 

Thus  R,  and  R.,  are  written  implicitlv  with  "data" 

6  7 

LOC  3  and  LOC  2+1,  respectively.  Choose  LOC  3 


different  from  LOC  2+1  and  also  different  from  ONE/ 


b,c)  LOC  3:  I^;  /l^  is  stored  in  LOC  3.  When  I  is  fetched, 

the  program  counter  is  read  out  implicitly  on 
the  address  bus;  expected  output  "data"  =  LOC  3. 

Thus,  Iy  is  the  first  instruction  in  the  subroutine. 

Iy  explicitly  reads  out  R^/ 

I  s  j  with  the  address  of  operand  ONE;  /R2  is  explicitly 

read  out.  and  R^  are  implicitly  read  out/ 

I7^;  :'"s  C^e  "ReCurn  from  subroutine"  instruction. 

The  contents  of  the  subroutine  register  (R^)  are  transferred 
to  the  program  counter.  The  next  instruction  will  be  fetched 
from  the  location  LOC  2  +  1,  as  LOC  2  +  1  is  the  return 
address  for  the  subroutine.  When  this  new  instruction  is 
fetched,  the  subroutine  register  will  be  effectively  read  out 
through  the  program  counter/ 

d)  A  *-  {R^  R2,  R4,  R5,  R6,  R?] 

e)  Q  «-  R3 

Iteration  6 

a)  with  operand  ZERO;  /I  is  stored  in  location  LOC  2+1. 

•'  *■  is  fetched  R^  is  implicitly  read  out  as  explained 


i  with  data  ZERO / 

T  JNE;  I2  with  operand  ONE; 

I ^ .  with  operand  ONE;  I ^  with  the  address  of  operand  ONE; 
/R^,  R2 ,  R^,  and  R^  are  written  with  "data"  ONE/ 
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Ig  with  jump  address  =  LOC  4;  /the  program  counter  implicitly 
written  with  LOC  4.  Choose  LOC  4  different  from  ZERO/ 

LOC  4:  I^q  with  jump  address  =  LOC  5;  /the  subroutine  register 
(R^)  is  written  implicitly  with  data  LOC  4  +  1. 

Choose  LOC  4+1  different  from  ZERO-  When  I2q  is 
fetched  the  program  counter  is  implicitly  read  out; 
expected  output  data  =  LOC  4/ 

b)  LOC  5:  ly  I g ;  1^;  I^7  with  the  address  of  operand  ONE; 

/R^  and  R£  are  explicitly  read  out;  R^  and  R^  are 
implicitly  read  out/ 

/causes  the  subroutine  register  (R7>  to  be 
implicitly  read  out  through  the  program  counter  when 
the  next  instruction  will  be  fetched  from  location 


LOC  4  +  1 

c)  LOC  4+1.  Ig ;  I7;  /R3  is  read  out  using  READ  (R^ )  =  (i^,  I7) 

sequence;  expected  output  data  =  ZERO-  When  1^  is 
fetched  R7  is  implicitly  read  out  as  explained  above/ 

d)  A  «-  { Rx ,  R2,  R^,  Rj,  Rfi,  Ry  R33 

e)  Q  empty 

Step  4 :  Repeat  steps  1,  2,  3  using  complementary  data.  □ 


The  generated  test  sequence  will  be  1^,  Iy  Ty  Ig»  Iy  I, > 

I15» . »  Iy  Ig,  I16,  I17,  l2V  I6>  Iy  Thus  the  "writing"  process 

involved  in  step  3(a),  and  the  "reading"  process  involved  in  step  3(b)  and 
(c),  do  involve  implicit  writing  and  reading  of  registers.  The  whole 
procedure  requires  careful  selection  of  "data",  i.e.,  both  the  operands 
and  address  of  operands.  The  jump  addresses  in  the  "Jump",  "Jump  to 


subroutine”,  and  "Return  from  subroutine1'  instructions  must  be  carefully 
chosen  to  avoid  reexecuting  the  already  executed  tests  or  overwriting 
the  ins tructions . 

We  now  present  a  lemma  describing  the  behavior  of  a  micro¬ 
processor  under  faulty  register  decoding.  This  will  then  be  used  to  prove 
that  the  tests  generated  using  Procedure  4.1  will  detect  any  detectable 
fault  in  the  register  decoding  function. 

Lemma  4.3:  Let  READ  (R.)  =  <1,  ,  I.  I.  ),  and  WRITE  (R. ) 

i  *1  x2  i 


=  <I„  ,  I  I 

Pn 


Pf  Pj 


a)  When  R.  is  written  with  data  d  by  executing  the  instructions 


in  the  WRITE  (R^)  sequence,  all  registers  in  the  set  f^  (D (WRITE  (R^ ) ) ) 


fQ(D(I^  ,  1^  1^  ))  are  written  with  data  d,  unless  (1).  f^CDCIp  )) 

for  some  I  €  WRITE  (R.),  1  £  j  s  n-1,  in  which  case  R.  is  written 

p .  i  l 

J 


with  either  a  ONE  or  a  ZERO  depending  on  technology,  or  (2).  f  (D(I  )) 

pn 


=  £-a],  in  which  case  the  contents  of  R^  remain  uncnanged. 


b)  When  R..  is  read  out  by  executing  the  instructions  in  the 


READ  (R^ )  sequence,  during  the  process  of  reading  out  R^  all  registers 


in  the  set  f  (D(I,  ,  I,  , .  .  .  ,  I,  ))  are  written  with  data  d  and  data  d 

D  K ..  tC0  K  , 

12  m-1 


is  read  out,  if  R,  contains  data  d,  unless  f  (S (I  ))  =  ii}.,  for  some 

x  UK. 

j 


I^  €  READ  (R^) ,  in  which  case  a  ONE  or  a  ZERO  will  be  read  out,  depending 

j  1 

on  technology. 

Proof :  The  lemma  follows  immediately  from  the  faulty  behavior 

of  the  register  decoding  function  f^.  Q 

Example  4.3:  With  reference  to  the  S-graph  of  Figure  2.3, 

READ  (R-)  =  -I, ,  I,)  and  WRI TE  (R_)  =  (I  ,  I.).  When  R„  is  written  with 
jo/  j  Ip  j 


ata  d  by  executing  I,  with  data  d,  and  Ic,  all  registers  in  the  set 
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fD (D (WRITE (R3)))  =  fD(D(I1,  I.))  =  fD(D(I1))  U  fQ (D (Ig))  =  f^)  U  f Q (R3 ) 
are  written  with  data  d,  unless  fQ(R^)  3  [0],  in  which  case  is  written 
with  either  a  ONE  or  a  ZERO,  or  f  (R^)  =  [0],  in  which  case  the  contents  of 

remain  unchanged.  When  R^  is  read  out  by  executing  1^  and  1^,  all  registers 
in  the  set  f^(R^)  are  written  with  data  d  and  data  d  is  read  out,  unless  fp(R^) 
=  [0]  or  fD(R3)  =  {0}  ,  in  which  case  either  a  ONE  or  a  ZERO  is  read  out. 

Theorem  4.1:  The  test  sequence  generated  by  using  Procedure 
4.1  is  capable  of  detecting  any  detectable  fault  in  the  fault  model  for  the 
register  decoding  function. 

Proof :  The  proof  is  by  induction.  At  the  beginning  of  step  3(a) 

of  Procedure  4.1,  let  set  A  = [r.  ,  R.  ,  . . . ,  R.  1.  Let  the  induction 

L1  X2  1k 

hypothesis  be  f  (R  )  A  f  (R .  )  H  ...  H  f  (R  )  =  [0},  and  f  (R  )  #  [0}, 
12  k  j 

for  each  R^  €  A.  At  the  end  of  step  3(d)  of  Procedure  4.1,  i.e.,  when 

j 

set  A  is  augmented,  let  set  A  =  [R.  ,  R.  ,  . . • ,  R.  ,  R.  }.  We  will 

Xl  x2  xk  ^k+l 

prove  that  f  (R.  )  H  f  (R.  )  fi  . T  f  (R.  )  H  f  (R.  r 

D  i2'  D '  Dv  ik+1)  =  [0;,  and 

fn(R,  )  *  {*}• 
u  \+l 

In  step  3(a),  registers  of  set  A  are  written  with  data  ONE  (ZERO), 

and  register  R.  ,  which  is  at  the  front  of  the  queue,  is  written  with 
Lk+1 

data  ZERO  (ONE),  by  executing*  the  instructions  in  the  corresponding  WRITE 

sequences-  If  fn(R-i  )  =  {0}-»  the  fault  will  be  readily  detected  when 

k+1 

appropriate  instructions  are  executed  to  read  out  R.  in  step  3(c),  as 

1k+l 

it  will  fail  to  produce  either  a  ONE  or  a  ZERO  following  Lemma  4.3.  Assume 

that  for  some  register  R.  of  set  A,  fn(R,  )  0  f  (R.  )  #  [0].  if  R,  is 

Xi  D  XZ  D  xk+l 

written  after  R.  in  step  3(a),  the  fault  will  be  detected  when 
k+1 


Though  strictly  speaking  Procedure  4.1  is  a 'test  generation  procedure 
in  the  proof  we  are  assuming  that  the  tests  are  executed. 


R.  is  read  out  in  step  3(c),  since  according  to  Lemma  4.3,  all  the 
k+1 

registers  in  the  set  f  (R.  ),  and  hence  in  the  set  fn(R.  )  r  f  (R.  ) 

D  H  D  Li  D  \+i 

will  be  written  with  ONE  (ZERO).  Since  f  (R.  )  H  f  (R.  )  »  f  (R.  ), 

D  xi  D  \+l  D  k+1 

when  R.  is  read  out  in  step  3(c),  it  will  either  produce  a  ONE 

\+l 

instead  of  a  ZERO,  or  a  ZERO  instead  of  a  ONE.  Note  that  since 

0(R.  )  5  £(R.  ),  the  process  of  reading  out  of  R.  will  not  require 

XZ  Lk+1  Xl 

routing  of  R.  through  R.  .  Similar  arguments  apply  when  R.  is 
xl  Lk+1  Xi 

written  before  R.  in  step  3(a).  In  this  case  the  fault  will  be 

Xk+l 

detected  when  R.  is  read  out  in  step  3(c). 

XZ 

The  basis  of  induction,  i.e.,  when  A  =  fR.  },  fL(R.  )  ^  {0}>  and 

1^  D 

when  A  =  [r  ,  R.  },  f  (R  )  H  f  (R  )  =  {0}  can  be  readily  proved  following 
L1  2  D  Xl  D  X2 

the  same  arguments  used  so  far.  Using  these  arguments,  it  is  guaranteed 
n 

that  H  f  (R.)  =  f  0 } ,  where  ft  =  [R,,  R~ . R  }.  Since  all  the  registers 

1=1  D  l  I  Z  n 

have  disjoint  image  sets  under  mapping  fQ,  f  cannot  be  a  many-to-one 
correspondence.  Moreover,  since  f^R^)  ^  {0}  for  each  R^  €  ft,  fQ  cannot 
be  a  one-to-many  correspondence  from  ft  to  ft.  Therefore  f^  is  guaranteed 
to  be  a  one-to-one  correspondence  from  ft  to  ft.  If  follows  immediately 
that  the  register  decoding  function  (denoted  by  f^)  is  free  of  any 
detectable  fault.  Note  that  for  some  registers,  even  if  fp(Ri. )  #  {R^},  f^ 
could  still  be  a  one-to-one  correspondence.  For  example,  we  may  have 
f^(R^)  =  £ R j }  and  f^(Rj)  =  { R^ } .  In  such  a  case,  the  fault  is  an 

u 


J 


undetectable  fault. 
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4.3.  Test  Generation  Procedures  for  Detecting  Faults  in  the  Instruction 
Decoding  and  Control  Function 

In  this  section  we  present  the  test  generation  procedures  to 

detect  faults  f (I ^ /0 ) ,  f(Ij/I^),  and  f(I^/I^+I^)  for  each  ordered  pair  of 

instructions  I ^  and  1^.  We  divide  the  overall  task  of  test  generation 

into  three  subtasks  depending  on  which  class  (T,  M,  or  B)  instructions 

I.  and  I  belong  to.  Following  this,  we  first  give  the  order  in  which 

3  k 

the  tests  are  applied,  and  then  describe  the  details  of  test  generation. 


The  overall  task  of  detecting  faults  in  the  instruction 


decoding  and  control  function  can  be  divided  into  three  subtasks. 

subtask  1:  Test  for  fault  f(I./0),  fCI./l.  ).  and  f  (l .  /I .  +1.  ) , 
-  j  '  j  k'}  Jjk 

where  I.  €  class  T,  and  I,  6  class  (T  U  M) . 
j  k  s 

subtask  2:  Test  for  faults  £(I./0),  £(!./!.).  and  £(I./I.+l.). 

-  J  j  k  ’  j  j  k 

where  I.  €  class  M,  and  I,  €  class  (T  U  M) . 

J  k 

subtask  3:  Test  for  faults  f(I./0),  f(I./I,),  and  f(I./I.+l  ), 

j  jk  JJk 

where  I.  €  class  B,  and  I,  €  class  (T  ij  M  IJ  B) ; 
j  k 

or  I .  €  class  (T  u  M)  and  I  €  class  B. 

J  k 

The  basic  philosophy  behind  this  task  division  is  to  employ  a 
systematic  approach  that  tackles  a  complex  problem  by  dividing  it  into 
logically  distinct  and  smaller  subproblems. 

9 

4.3.1.  Order  of  Test  Application 
i 

Before  presenting  the  details  of  test  generation,  we  first 


describe  the  order  in  which  the  tests  are  applied.  The  tests  for  each 
subtask  described  above  are  to  be  executed  by  the  microprocessor  under 
test  in  the  order  given  below. 
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First  we  concentrate  on  instructions  with  label  1,  i.e., 

4  (I . )  =  4(1  )  =  1,  and  apply  tests  to  detect  faults  f(I./0),  f(I./I,  ), 
j  k  J  J  k 

and  f(I./l.+I,  ).  Then  we  apply  tests  to  detect  faults  f(I./I.+I,  ), 

J  J  k  J  J  k 

where  4(1.)  =  1  and  4(1  )  =  2.  This  is  followed  by  tests  to  detect 
J  K 

faults  f(I./I.+I,  ),  where  2  £  4(i.)  £  k  and  4(1  )  =  1.  (K 

j  j  k  j  max  k  max 

indicates  the  maximum  value  of  the  labels  of  edges  representing  instruc¬ 
tions  in  the  S-graph.)  Thus  we  check  that  all  instructions  with  label  1 
are  decoded  correctly,  no  instruction  with  label  1  causes  additional 
execution  of  an  instruction  with  label  2,  and  no  instruction  with  a 
label  greater  than  1  causes  additional  execution  of  an  instruction  with 
label  1.  This  procedure  can  be  easily  generalized  and  is  given  in  a 
precise  algorithmic  form  below. 

Algorithm  4.2:  Algorithm  to  determine  the  order  of  test 

application  for  detecting  f(I;/0),  f(I,/I,  ),  and  f(I,/I.+I,  ) 

J  J  R  J  J  R 

FOR  K  1  TO  K  DO 
max 

Apply  tests  to  detect  faults  f(I./0),  f(I./I,), 

J  JR 

and  f (I . /I .+1  )  where  4  (I . )  =  4(1)  =  K. 
j  j  k  j  k 

Apply  tests  to  detect  faults  f(I^./lj+I^),  where 

1  *  4(1  )  *  K,  4(lk)  =  K  +  1,  and  K  <  K^. 

Apply  tests  to  detect  faults  f(lVlj+Ik),  where 

K  +  1  *  4(1  .)  «  K  ,  4(1,  )  =  K. 
j  max  k 

Strictly  speaking,  this  order  need  not  be  followed  during 
the  actual  application  of  tests,  but  it  plays  a  very  crucial  role  in 


BEGIN 
Step  1: 

Step  2  : 

Step  3: 

END 
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proving  that  the  tests  detect  faults  in  the  instruction  decoding  and 
control  function.  Therefore  we  assume  that  the  tests  are  applied  in  the 
order  given  by  Algorithm  4.2. 


Note  that  in  steps  2  and  3  it  is  not  necessary  to  check  for 

faults  f(I./0)  or  f(I./I,  )  because  these  faults  are  detected  by  tests 
J  J  k 

involved  in  step  1.  We  now  present  an  example  to  illustrate  the  three 
steps  of  the  algorithm. 

For  concise  representation  we  introduce  some  notation  at  this 

stage.  Let  I  ,  I  ,  etc.,  denote  sets  of  instructions.  Then  f (I  /I  ) 

A  d  A  13 

would  denote  a  set  of  faults  given  by  ff(I./I.)  I  I.  €  I  and  I.  6  I  }. 

1  1  j  1  i  A  j  B 

For  example,  let  =  £l x ,  12)  and  =  [Lj,  1^},  then  f(IA/lB)  = 

£f(I1/l3),  f(I1/l4),  f(I2/l3),  f(I2/l4)}.  Similarly  fttA/lA+IB)  and 
f(I  /0)  denote  the  corresponding  sets  of  faults.  Needless  to  say,  we  do 
not  incorporate  f(I./l.)  or  f(I./I.+I.)  in  the  sets  f(I,/l_)  or  f(IA/l  +I_). 
i  (I  )  denotes  the  set  of  labels  of  instructions  in  set  I  . 

A  A 

Example  4.4:  This  example  illustrates  the  steps  of 
Algorithm  4.2  in  the  case  of  subtask  1  for  the  S-graph  of  Figure  2.8. 
Iteration  1 


Step  1:  Apply  tests  for  faults  f(I  /Q),  f(I  /I  ),  and  f(IA/l  +1  ) 
where  IA  =  *B  ^7>  Igt  I16»  x17»  I18»  Ii9^’  and 
i(IA)  =  i(IB}  =  fl}- 

Step  2 :  Apply  tests  for  faults  f(I^/l^+IB)  where  1^  =  (ly »  Ig,  I^6» 

I17’  1 18 *  ri9^’  IB  =  'II’  I2’  I3’  I4’  I6’  111’  I12’  ri3’  I15^’ 
and  £(Ia)  =  {1},  *(IB)  =  12}. 

Step  3:  Apply  tests  for  faults  f(I  /I^+I  )  where  I  =  [i ^ ,  I3 , 

I5’  I6’  1 15 " ’  IB  “  lI7’  I8’  I16’  I17’  I18’  I19^’  and 


5*^ 
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2(1.)  =  [2,  3},  2(i  )  =  Cl}- 


Iteration  2 : 


Step  1:  Apply  tests  for  faults  f (I  /<£),  f  (I  /I  ) ,  and  f(I  /I  +1  ) 

A  Ad  A  A  ij 

l3’  V  "6 


A"'*  "  '■'"‘A  B  ’  v  A  A  By 

where  IA  =  £l x »  I2>  X3>  I6J  I15^’  IB  =  ^l’  I2’  I3’  I4’  I6’ 
IH,  I12>  I13»  I153.  and  £(Ia)  =  2(1^  =  2. 

Step  2 :  Apply  tests  for  faults  f (IA /lA+IB )  where  IA  =  [i^,  Ig,  I  g, 


17 


*  I18>  I19’  II’  I2’  I3J  I6  ’  X15^’  IB  ~  ’  3nd 


2(1.)  =  Cl,  2],  2( I  )  =  [3}. 


Step  3:  Apply  tests  for  faults  f(I  /I  +1  )  where  I  =  Clq], 

A  A  D  A  3 

rB  =  ■II’  I2’  X3 5  I4’  X6’  111*  I12’  I13’  I15"’  and 


2(Ia)  -  C 3 } ,  1(IB)  =  £2} . 


Iteration  3: 

Step  1:  Apply  tests  for  fault  f(Ig/0).  (Note  that  2(1.)  =  {3}.)  ^ 

The  next  job  is  to  develop  the  details  of  test  generation  for 
detecting  faults  f  (I  ^  /0  )  ,  f(Ij/I^),  and  f(Ij/I^+I^).  These  details 
depend  very  heavily  on  the  labels  of  instructions  and  their  source  and 
destination  registers.  Therefore  we  partition  the  job  into  various  cases 
depending  on  these  labels  and  present  the  test  generation  procedure  for 
each  case. 


At  this  stage  we  make  an  assumption  about  the  labels  of  edges 

representing  instructions.  If  1^  €  class  M  then  2(1^)  5  2 ,  i.e.,  if 

2(1.)  >  2  then  I.  €  class  T.  Recall  from  Lemma  4.2  that  all  instructions 
J  J 

of  class  B  are  labeled  1.  Thus  the  destination  of  an  instruction  of 
class  M  can  only  be  a  main  memory  location  or  a  register  with  label  1. 
This  assumption  can  be  easily  justified  for  available  microprocessors, 
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since  the  result  of  an  instruction  of  class  M  is  usually  stored  in  a  main 
memory  location  or  an  accumulator  [Cush77] ;  on  the  other  hand,  the 
destination  register  of  an  instruction  of  class  T  can  have  any  label. 
Without  this  assumption  the  details  of  the  test  generation  procedures 
become  extremely  complicated. 


4.3-2.  Test  Generation  for  fCl./d) 

- - - — 

The  details  of  test  generation  depend  principally  on  £(1.). 

We  consider  three  cases,  namely,  case  A(l),  case  A(2),  and  case  A(3), 
depending  on  The  suffix  A  is  used  to  denote  that  a  case  belongs 

to  the  details  of  test  generation  for  f(I  /0).  These  cases  are  divided 
into  subcases  which  are  listed  in  Table  4.1.  For  each  subcase,  the 
table  gives  which  test  generation  procedure  is  applicable  and  which 
theorem  proves  the  fault  coverage. 


4. 3. 2.1.  Test  Generation  tor  fCl^/0)  When  1C T.)  =  1 

This  case  is  referred  to  as  case  A  Cl)  and  is  divided  into 


two  subcases . 

Case  A(l. 1) :  OUT  €  0(1^),  i.e.,  I  is  expected  to  read  out  a 
register  with  label  1  (according  to  Lemma  4.1). 

Case  A(1 .2) :  I ^  is  an  instruction  of  class  B  not  represented 
in  the  S-graph,  i.e.,  I ^  only  changes  the  logic  level  on  some  status  pins. 

In  either  subcase  the  fault  detection  is  easy  since  I.  has  the 


highest  observability  as  signified  by  fl(I  )  =  1. 

We  give  the  test  generation  procedures  below.  It  is  straight¬ 


forward  to  derive  the  tests  in  terms  of  the  assembly  language  instructions 
of  the  microprocessor  to  be  tested  from  the  procedures  to  follow.  For 


f  test  generation  for  detecting  f( 
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conciseness  we  say  that  the  microprocessor  executes  these  procedures 
instead  of  saying  that  the  microprocessor  executes  the  tests  generated  by 
these  procedures.  For  the  same  reason  we  treat  these  procedures  as  if 
they  are  test  execution  procedures  instead  of  test  generation  procedures. 
We  denote  various  operands  for  instructions  by  OPERAND  1,  OPERAND  2  ,  etc. 
and  various  results  stored  in  registers  (as  a  consequence  of  instruction 
execution)  by  RESULT  1,  RESULT  2  ,  etc. 

Procedure  4.2: 


This  procedure  is  applicable  for  case  A(l.l).  It 


generates  tests  to  detect  fault  f(I./0)  when  4(1.)  =  1  and  OUT  €  D(I.) 


J 


Step  1:  Store  proper  operand (s)  in  S(Ij)  such  that  when  I.  is 


executed,  the  expected  output  "data"  is  different  from  the 
quiescent  logic  value  on  the  data  (or  address)  bus. 


Step  2 :  Execute  . 


□ 


Procedure  4.3: 


This  procedure  is  applicable  for  case  A(1.2).  It 


generates  tests  to  detect  fault  f(lV0)  when  4(1^)  =  1  and  I  belongs  to 


class  B  but  it  is  not  represented  in  the  S  graph. 

Step  1:  Execute  the  proper  instruction  to  set  up  the  logic  value  on  a 


status  pin  to  x  (x  6  [0,  l})  if  the  instruction  I ^  under 


consideration,  when  executed,  sets  up  the  logic  value  on  that 
status  pin  to  x- 

Step  2 :  Execute  I . .  C 


This  case  is  referred  to  as  case  A  (2 ) .  In  this  case 

|  READ  (D  (I  . ) )  |  =  1-  Let  READ  (D(I  ))  =  \I  )■  Of  course,  )  =  1, 

J  J  ^  K 

and  by  definition  of  the  READ  sequence  £  (  T  U  B)  and  OUT  €  D(I^). 
Procedure  4.4: 

This  procedure  is  applicable  for  case  A(2).  It  generates 
tests  to  detect  fault  f (I  J<t>).  when  1(1^)  =  2. 

Step  1:  Store  OPERAND  1  in  D(IJ  and  proper  operand(s)  in  S(IJ 

such  that  when  1^  is  executed  it  produces  RESULT  1 

in  D  (I j ) *  and  RESULT  1  #  OPERAND  1. 

Step  2 :  Read  out  D(I^)  by  executing  READ  (D (I j ) ) . 

/Expected  output  data  =  OPERAND  1/ 

Step  3 :  Execute  I  .  . 

- 1 -  J 

Step  4:  Read  out  D(I.)  by  executing  READ  (D(I^)). 

/Expected  output  data  =  RESULT  1/  L- 

Example  4.5:  This  example  (depicted  in  Figure  4.1) 

illustrates  Procedure  4.4.  I.  is  an  "Add"  instruction  which  adds 

J 

the  contents  of  registers  R^  and  R2  and  stores  the  result  in  R^  • 

READ  (D (I  . ) )  =  (i,  ),  i(I.)  =  1  and  I  €  class  T.  OPERAND  1 

J  K  tC  rC 

can  be  chosen  to  be  ONE,  and  RESULT  1  to  be  ZERO,  requiring  that 
operand  ZERO  be  stored  in  both  R^  and  R9 .  1^  is  executed  to  make 

sure  that  R^  does  store  OPERAND  1.  This  is  followed  by  execution  of 
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Theorem  4.2:  Procedure  4.4  detects  f(I^/0)  in  case  A(2). 

Proof :  Note  that  0(1^)  =  1  where  READ  (D (I j ) )  =  (i^). 

(Refer  to  Figure  4.1.)  Since  the  tests  are  applied  in  the  order 

specified  by  Algorithm  4.2,  the  microprocessor  under  test  executes  this 

procedure  after  executing  the  tests  required  to  detect  f(I  /0), 

P 

f(I  /I  ),  and  f(I  /I  +1  )  where  0(1  )  =  4(1  )  =  1,  and  f  (I  /I  +1  ) 
p  q  p  p  q  p  q  v  v  v  w' 

where  0(1^)  *  1  and  0(1^)  =  2.  Therefore,  when  the  microprocessor  under 

test  executes  this  procedure  it  has  been  already  checked  that  the 

READ  (D(I.))  =  (i,  )  sequence  can  correctly  read  out  D(I.)  and  its 
J  k  J 

execution  does  not  cause  additional  execution  of  any  instruction  with 
label  2;  in  particular  the  contents  of  D(Ij)  are  not  changed  after 
the  execution  of  READ  (D(I^)).  Therefore  step  2  ensures  that  D(I^) 
stores  OPERAND  1.  This  step  is  necessary  because  due  to  faults 
involved  in  the  instructions  used  to  write  data  in  D(I^),  RESULT  1 
may  be  stored  in  D(I^)  instead  of  OPERAND  1.  If  step  2  is  not  executed, 
the  fault  f(I_./0)  will  be  masked. 

In  step  3,  1^  is  executed  which  is  expected  to  produce  RESULT  1 
in  D(Ij).  If  f(Ij/0)  is  present,  the  contents  of  D(I  )  will  not 
change.  Consequently  when  D (I ^ )  is  read  out  in  step  4  the  fault  will 
be  detected. 


4. 3. 2. 3.  Test  Generation  for  f(I./0)  When  0(1.)  =  K  2  3 

- i-j — - - 

This  case  is  referred  to  as  case  A  (3 )  ■  According  to  our 


assumption  in  Section  4-3.1,  1^.  "  class  T.  This  case  is  divided  into 


two  subcases  . 
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Case  A(3 . 1) :  S(Ij)  is  not  the  destination  register  of  any 
instruction  belonging  to  the  READ  (D (I j  > >  sequence.  Figure  4.2  illustrates 
this  case,  4(1  )  =  K  2  3,  ) )  =  K-l,  4(8(1^))  =  K,  and  READ  (D(Ij)) 

=  (i  ,  I  ,  ....  1  )•  Thus  it  is  possible  to  read  out  D(I.)  without 


PK-l'  PK-2 


1 


routing  the  contents  of  D  (I j )  through  S  (I ^ ) -  In  this  case  we  follow 
Procedure  4.4.  (The  same  procedure  which  is  used  in  case  A (2).) 

Theorem  4.3:  Procedure  4.4  detects  f(lV0)  in  case  A(3.1). 

Proof:  The  proof  follows  the  same  arguments  given  for  the 
proof  of  Theorem  4.2,  except  for  one  change.  The  microprocessor  under 
test  executes  this  procedure  after  executing  the  tests  required  to  detect 
f  (I  f(I  /I  ),  f(I  /I  +1  )  where  1  ),  4(1  )  *  K-l,  and 

f(Iv/Iv+I  )  where  1  ^  1(1^)  *  K-l  and  4(Iw)  -  K.  Note  that  in  this  case 

READ  (D  (I  . ) )  =  (i  ,  I.  ,  ...»  I  >  as  illustrated  in  Figure  4.2. 

J  PK-1  PK-2  P1 

Since  4(d(I.))  =  K-l,  4(1  )  =  i>  for  1  s  i  ^  K-l. 

J  Fi 

Therefore,  when  the  microprocessor  under  test  executes  this 
procedure  it  has  been  already  checked  that  the  execution  of  any 


instruction  I  €  READ  (D(I.))  does  not  give  rise  to  the  additional  execution 
Pi  J 

of  any  instruction  with  label  K.  D(I^)  can  be  correctly  read  out  by  executing 
READ  (D (I j ) )  in  step  2  of  this  procedure,  and  after  the  execution  of 
READ  (D(I j ) )  the  contents  of  D(Ij)  are  not  changed  (note  that 
4(D(Ij))  ■  K-l  and  4(1^)  =  K) .  All  the  remaining  arguments  are  exactly 
the  same  as  given  in  the  proof  of  Theorem  4.2. 


□ 


Case  A(3 .2) :  S(Ij)  is  the  destination  register  of  an  instruc¬ 
tion  belonging  to  the  READ  (D(I.))  sequence.  Figure  4.3  illustrates  this 
case;  1(1.)  =  K  2  3 ,  4(D(I.))  =  K-l,  4(S(I.))  =  K-2. 
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READ  (D  (I.))  =  (i  ,1  I  )  and  READ  (S  (I .))  =<I 

J  K-l  PK-2  P1  J  PK-2 

I_  ,  I  >  where  2(1  )  »  i  for  1  s  i  s  K-l.  Let  I  €  WRITE (S(I.)) 

pK-3  P1  pi  s  j 

and  D(I  )  =  S(I.>.  Therefore,  2(1  )  =  K-l,  and  2(S(I  ))  =  K-l. 

S  J  s  s 

Procedure  4.5: 

This  procedure  is  applicable  for  case  A(3.2).  It  generates 
tests  to  detect  fault  f(I  J<t)  when  2(1^)  =  K  s  3,  and  S(I^)  is  the 
destination  register  of  an  instruction  belonging  to  the  READ  (D (I j ) ) 
sequence . 


Step  1:  Store  OPERAND  1  in  D(I^)  by  executing  WRITE  (D(I.)). 

Step  2:  Read  out  D(I^)  by  executing  READ  (D(I^)). 

/Expected  output  data  =  OPERAND  1/ 

Step  3:  Store  OPERAND  2  +  OPERAND  1  in  S (I  )  by  executing  WRITE  (S(I  )). 

s  s 

Step  4:  Read  out  D(Ij)  by  executing  READ  (D(Ij)). 

/Expected  output  data  =  OPERAND  1/ 


Step  5:  Execute  I  and  I..  /Refer  to  Figure  4.3/ 

S  J 

Step  6:  Read  out  0(1^)  by  executing  READ  (D(Ij)). 

/Expected  output  data  =  OPERAND  2  ^  OPERAND  1/ 


H 


Theorem  4.4:  Procedure  4.5  detects  f (I ^ /© )  in  case  A(3.2). 


Proof :  1  5  2(1  )  *  i  ^  K-l,  for  each  instruction  I  in  the 

Pi  Pi 

READ  (D(Ij))  sequence.  When  the  microprocessor  under  test  executes  this 

procedure  it  has  already  executed  the  tests  required  to  detect 

f(I  /I  )  and  f(I  /I  +1  )  where  1  «  f(I  ),  f(I  )  s  K-l,  and  f (I  /I  +1  ) 
p  q  p  p  q  p  q  v  v  w 

where  1  s  2(1  )  ^  K-l  and  2(1  )  =  K. 

v  w 


J 
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Therefore,  when  the  microprocessor  under  test  executes  this 

procedure  it  has  been  already  checked  that  the  READ  (D(I^))  sequence  can 

correctly  read  out  D(Ij)  and  the  execution  of  any  instruction  in  this 

sequence  will  not  give  rise  to  additional  execution  of  any  instruction  with 

label  K;  in  particular  the  contents  of  D(I.)  and  S(I  )  remain  unchanged. 

1  s 

(Note  that  2(D(I.))  =  2(S(I  ))  =  K-l.)  Moreover,  the  execution  of  I 
J  s  s 

does  not  give  rise  to  additional  execution  of  any  instruction  with 

label  K,  since  2(1  )  =  K-l;  thus  in  particular  the  contents  of  D(I.) 

s  J 

remain  unchanged  after  the  execution  of  Ig. 

In  step  2,  D(Ij)  is  correctly  read  out  by  executing  READ  (0(1^)) 

and  it  continues  to  store  the  operand  stored  in  it,  i.e.,  OPERAND  1, 

after  this  "read  out"  process.  In  step  3,  S(I  )  is  written  with  OPERAND  2 

s 

by  executing  WRITE  (S(I  )).  Since  2(S(I  ))  =  2(D(I.))  =  K-l,  it  is 

s  s  j 

possible  to  write  data  in  S (I  )  without  routing  it  through  D(I.)  during 

s  J 

the  execution  of  WRITE  (S(I  ))•  Step  4  ensures  that  D(I.)  continues  to 

s  j 

store  OPERAND  1  after  step  3.  Moreover,  D(I.)  and  S(I  )  continue  to 

J  s 

store  OPERAND  1  and  OPERAND  2  ,  respectively,  after  the  "read  out" 
process  in  step  4. 

Since  2(1^)  =  K_l>  the  execution  of  I  in  step  5  will  correctly 

transfer  the  contents  of  S (I  )  to  S(I.),  i.e.,  S(I.)  now  contains 

s  j  J 

OPERAND  2  4  OPERAND  1.  Also  the  contents  of  D(I^)  remain  unchanged,  since 

2(1  )  ■  K-l  and  2(D(I.))  =  K-l.  After  this  I.  is  executed  which  is 
s  J  J 

expected  to  change  the  contents  of  D(Ij)  to  OPERAND  2 .  If  f(lV0)  exists, 

I.  will  fail  to  do  so  and  the  fault  will  be  detected  when  D(I.)  is  read 
J  J 

out  in  step  6.  fj 
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4.3.3.  Test  Generation  for  fCI^/I^) 

The  details  of  test  generation  depend  principally  on  2(1^)  and 

4(1.).  We  consider  three  cases,  namely,  case  B(l),  case  B(2),  and 

case  B(3)  depending  on  2(1^).  The  suffix  B  is  used  to  denote  that  a  case 

belongs  to  the  details  of  test  generation  for  f(I./I,  ).  These  cases  are 

J  k 

divided  into  subcases  which  are  listen  in  Table  4.2.  For  each  case,  the 
table  gives  which  test  generation  procedure  is  applicable  and  which 
theorem  proves  the  fault  coverage. 

4.3.3. 1.  Test  Generation  for  ffl./l,  )  when  1(1.)  =  1 

- j  — - — j  -l - 

This  case  is  referred  to  as  case  B(l)  and  is  divided  into  two 
subcases  depending  on  2(1^). 

Case  B(  1  - 1) ;  2(1  )  s  2.  Since  2(1.)  =  1,  the  results  of  the 

™  k  J 

execution  of  I.  are  directly  observable  while  those  of  I,  are  not.  Hence 
j  k 

the  behavior  of  the  microprocessor  as  observed  at  its  external  pins 

under  the  fault  f(I./I_  )  is  the  same  as  it  would  be  under  the  fault 
J  k 

f (I  /0 ) .  Therefore  Procedures  4.2  and  4.3  given  in  Section  4. 3. 2.1  should 
be  followed  in  this  case . 

Case  B(1.2) :  2(1.)  =  2(1  )  =  1.  Many  of  the  faults  in  this 

J  k 

case  would  be  readily  detected  because  1^  and  1^  have  the  highest 
observability.  For  example,  1^  and  1^  may  read  and  write  data  into  the 
main  memory  during  different  machine  cycles  of  the  corresponding  instruc¬ 
tion  cycles;  or  during  the  execution  of  1^  and  1^  a  different  sequence  of 
status  signals  may  be  emitted  on  the  status  pins.  Therefore  we  will 
explicitly  discuss  the  detection  of  those  faults  which  cannot  be  easily 
detected  in  this  fashion.  This  case  can  be  further  divided  into  two 
subcases,  namely,  case  B(1.2.1)  and  case  B(1.2.2)  as  described  below. 


Case  and  its  description  Test  generation 
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l  (S (Ifc) >  =  K  Procedure  4.10 

Fault  coverage  follows  inmediately  from  the  description  of  the  procedure. 

Fault  coverage  can  be  proved  by  following  arguments  similar  to  those  in  the  proof  of  the 
(marked  with  t) . 


The  tests  generated  by  Procedure  4.6  for  case  B ( 1 . 2 - 1 )  are  to  be  applied 
before  those  generated  by  Procedures  4.7  and  4.8  for  case  B(1.2.2). 


Case  BC1.2.1):  During  the  execution  of  instructions  I .  and  I 

J  k 

the  results  of  the  operations  performed  are  "read  out".  The  operation 
performed  could  be  as  simple  as  a  data  transfer  from  a  register  to  the 
main  memory.  Examples  of  this  case  are  given  below. 

Example  4.6:  Instruction  I ^  is  "Store  the  contents  of  register 
R^  into  the  main  memory  using  direct  addressing,"  and  instruction  I  is 
"Store  the  contents  of  register  R£  into  the  main  memory  using  direct 
addressing . " 


Now  consider  another  example.  Instruction  I ^  is  "Add  the  contents 

of  the  accumulator  and  the  contents  stored  at  the  top  of  a  LIFO  stack 

(maintained  in  the  main  memory)  and  store  the  result  at  the  top  of  the  stack," 

and  instruction  I,  is  "Subtract  the  contents  of  the  accumulator  from  the 
k 

contents  stored  at  the  top  of  the  LIFO  stack  and  store  the  result  at  the 
top  of  the  stack."  ,  ~ 


Procedure  4.6: 

This  procedure  is  applicable  for  case  B ( 1 . 2 . 1 ) .  It 

generates  tests  to  detect  fault  f(I./l,  )  when  i( I.)  =  £(I  )  =  1  and  during 

J  k  j  k 

the  execution  of  I.  and  I,  the  results  of  the  operations  are  read  out. 

J  K 


Step  1: 


Step  2  : 
Step  3: 


Store  proper  operands  in  S(I^)  and  S(I^)  such  that  when  I  is 
executed  RESULT  1  is  read  out  and  when  1^  is  executed  RESULT  2  is 
read  out,  and  RESULT  1  #  RESULT  2  . 

Execute  I..  /Expected  output  data  =  RESULT  1/ 

Execute  1^.  /Expected  output  data  =  RESULT  2/ 
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Theorem  4 .5 : 


Procedure  4.6  detects 


f(VV 


in  case  B(1 .2 . 1) . 


Proof :  If  the  proper  operands  are,,  really  stored  in  S  (I  )  in 
step  1  so  that  RESULT  2  is  read  out  when  I,  is  executed,  the  fault  will  be 
detected  in  step  2  itself,  as  RESULT  2  will  be  read  out  (instead  of  expected 
output  data  =  RESULT  1)  . 

On  the  other  hand,  if  the  required  operands  are  not  stored  in 
S(I^.)  due  to  faults  involved  in  the  instructions  used  to  write  data  in 
S(I,  ),  the  fault  may  not  be  detected  in  step  2;  the  execution  of  I  may 
read  out  RESULT  1  as  the  wrong  operands  are  stored  in  S(I,  )•  But  in  this 

iC 

case  the  fault  will  be  detected  in  step  3  as  the  execution  of  I,  will 

k 

produce  RESULT  1.  Note  that  if  f(I./I  )  is  present  we  assume  that  I  is 

J  K  k 

correctly  executed.  (Recall  the  fault  model  in  Section  3.2.)  G 

Case  B(1.2.2):  During  the  execution  of  instructions  I  and 
1^  the  results  of  the  operations  performed  are  stored  in  registers. 

(The  results  are  not  read  out  as  in  case  B(1.2.1).)  The  operation  performed 
could  be  as  simple  as  a  data  transfer  from  a  main  memory  location  to  a 
register.  In  this  situation  the  instruction  belongs  to  class  T.  If  the 
operation  involves  some  data  manipulation,  the  instruction  belongs  to 
class  M. 


Note  that  1(1.)  =  1(1,  )  =  1.  If  the  instruction  I.  or  I.  belongs 
j  k  j  k 

to  class  M,  at  least  one  of  the  operands  for  I  or  1^  must  be  stored  ir. 
the  main  memory.  (If  all  the  operands  for  I  and  1^  are  available  in 
registers  we  would  have  l( I.),  1(1,  )  s  2.  Refer  to  step  4  of  the  labeling 

j  K 

algorithm  given  in  Section  4.1.)  The  address  of  the  operand  stored  in 
the  main  memory  is  computed  and  then  transferred  from  a  register  holding 
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it  to  the  address  register  of  the  main  memory.  Thus  the  register  storing 

the  address  of  the  operand  is  implicitly  read  out  during  the  execution 

of  I.  and  I,  .  This  is  precisely  the  reason  to  assign  label  1  to  I .  and  I,  . 
j  k  j  k 

(Refer  to  step  3  of  the  labeling  algorithm.)  As  mentioned  earlier,  the 
results  of  operations  performed  under  1^  and  are  stored  in  registers. 

If  the  instruction  belongs  to  class  M,  the  result  produced  is  stored  in 
a  register  with  label  1.  This  is  consistent  with  the  assumption  (regarding 
the  label  of  an  instruction  of  class  M)  made  in  Section  4.3.1. 

If  the  instruction  belongs  to  class  T  the  data  transferred  from 
the  main  memory  may  be  stored  in  a  register  with  label  greater  than  1. 

In  this  situation  fault  detection  may  or  may  not  be  easy  as  illustrated 
in  the  following  example. 


Example  4-7:  Let  instruction  I ^  be  "Load  the  contents  of  the 
memory  location  pointed  to  by  register  in  register  R2’"  and  leC 
instruction  1^  be  "Load  the  contents  of  the  memory  location  pointed  to  by 
register  in  register  R7-"  Both  instructions  store  the  result  of  their 
operation  (which  is  a  simple  data  transfer)  in  register  R? .  Even  if 
4(R9)  -  2,  fault  f(I./l  )  can  be  easily  detected  by  choosing  different 
addresses  (pointers)  in  R^  and  R^ .  If  f(lVl^)  is  present,  the  address 
stored  in  R^  will  be  (implicitly)  read  out  on  the  address  bus  instead  of 
the  address  stored  in  R^  when  I ^  is  executed,  and  the  fault  will  be  detected. 
Thus  this  case  is  really  not  different  from  case  B(1.2.1). 


We  now  consider  another  example  where  the  fault  detection  is  not 


so  easy.  Let  instruction  I ^  be  "Load  the  contents  of  the  memory  location 
pointed  to  by  register  R^  in  register  R2,"  and  let  instruction  1^  be 
"Load  the  contents  of  the  memory  location  pointed  to  by  register  R^  in 
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register  R  In  this  case  f(I./I,  )  can  be  detected  by  storing  different 
3  J  K 

data  in  R£  and  R^  and  then  reading  out  these  registers  by  executing 

READ  (R2)  and  READ  (R^)  •  If  2^)  or  2(R^)  i-s  greater  than  1,  (i.e.,  READ  (R2) 

or  READ  (R^)  contain  instructions  with  label  greater  than  1)  it  is 

not  guaranteed  that  READ  (R2)  and  READ  (R^)  sequences  can  correctly  read 

out  R?  and  R^  because  the  microprocessor  under  test  has  not  yet  executed 

tests  to  detect  f(I  /I  ),  f(I  /I  +1  )  where  2 (I  ),  2( I  )  a  2.  In  this 

p  q  p  p  q  p  q 

case  we  treat  I.  and  I  as  if  they  have  label  2(R  )  +  1  and  2(R  )  +  1, 

J  tC  u  J 

respectively,  as  far  as  the  test  generation  for  faults  f(I./I  ), 

J  k 

f(I./l.+I,),  f(I,  /I.),  or  f(I, /I  +1.)  is  concerned.  rp 

J  J  k  k  j  k  k  j  ~J 

Case  B(1.2.2)  being  considered  applies  only  to  those  instruc¬ 
tions  which  store  their  result  in  a  register  with  label  1.  Depending 

on  whether  the  results  of  I.  and  I,  are  stored  in  the  same  or  different 

J  k 

registers  we  divide  this  case  further  into  two  subcases. 

Case  B(1 .2 .2 . 1) :  The  results  produced  by  executing  instructions 

Ij  and  1^  are  stored  in  the  same  register.  Let  this  register  be  designated 

as  R  ;  furthermore,  let  READ  (R  )  =  (i  )•  Note  that  2(1  )=  1.  An 
P  P  P  P 

example  of  this  case  is  given  below. 

Example  4.8:  Instruction  1^  is  "Add  the  contents  of  the 

accumulator  and  the  contents  of  the  memory  location  (next  to  the  one  storing 

the  opcode  of  instruction  1^)  and  store  the  result  in  the  accumulator," 

and  instruction  I,  is  "Subtract  the  contents  of  the  accumulator  from  the 
k 

contents  of  the  memory  location  and  store  the  result  in  the  accumulator."  l2 
Procedure  4.7: 

This  procedure  is  applicable  for  case  B(1.2.2.1).  It 

generates  tests  to  detect  fault  f(I./I,  )  when  2(1.)  =  2(1  )  =  1,  and  during 

J  k  J  k 
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the  execution  of  I.  and  I,  the  results  of  the  operations  are  stored  in  the 
J  k 

same  register  R  . 

P 

Step  1:  Store  proper  operands  in  S (I . )  and  S(I  )  such  that  when 

J  k 

I  .  is  executed  RESULT  1  is  produced  and  when  I  is  executed 
J  k 

RESULT  2  is  produced,  and  RESULT  1  t  RESULT  2 

Step  2:  If  R  €  S(I.)  'J  S(I.)  then  read  out  register  R  by  executing 

-  p  j  X  P 

READ  (R  )  “  -I  ).  /To  make  sure  that  R  contains  proper 
P  P  P 

operand  to  be  stored  in  step  1.  The  other  member  of  S(I  .)  or 

S (It.)  i-s  J  location  in  the  main  memory./ 

Step  3:  If  R  S  S  (I . )  S(I,  )  then  repeat  step  2. 

- e —  P  j  k 

Step  4:  Execute  I ^ • 

Step  5:  Read  out  register  R  by  executing  READ  (R  )  *  (i  ) . 

- —  p  P  P 

/Expected  output  data  *  RESULT  1  /  G 

Theorem  4.6:  Procedure  4.7  detects  f(I./l,)  in  case  B(1.2.2.1). 

J  k 

Proof:  If  the  register  Rp  is  a  member  of  S(I^)  or  S(I^)  it 
must  be  ensured  that  it  contains  the  proper  operand  to  be  stored  in  step  1, 
otherwise  1^  could  produce  RESULT  1  instead  of  RESULT  2  and  fault  masking 
would  occur. 


The  instruction  I  involved  in  step  2  will  correctly  read  out 
P 

R  because  1 (I  )  =  1,  and  the  microprocessor  under  test  would  have 
P  P 

already  executed  the  tests  to  detect  f(I  /I^)  where  2(1^)  =  1  (generated 

by  Procedure  4.6  for  case  B(1.2.1));  however,  if  the  fault  f(I  /I  +1  .) 

P  P  P 

is  present,  where  2(1  ,)  =  2  and  D(I  ,)  ~  rR  ,  the  contents  of  R  may 

P  P  P  P 

change  after  it  is  read  out  by  executing  I  .  If  this  happens  it  will  be 

P 

detected  in  step  3.  On  the  other  hand  if  the  contents  of  R^  do  not  change 
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after  the  first  execution  of  I  (in  step  2),  they  will  not  change  after 

P 

the  second  execution  of  I  (in  step  3)  either. 

P 

In  step  4  1^  is  executed.  If  is  present,  RESULT  2  will 

be  produced  in  R^  in  step  4,  and  it  will  be  detected  when  R^  is  read 
out  in  step  5.  Q 

Case  B(  1 .2 ■ 2 .2) :  The  results  produced  by  executing  instruc¬ 
tions  Ij  and  1^  are  stored  in  different  registers.  Let  the  result 

produced  by  I .  be  stored  in  register  R  .  Furthermore,  let  READ  (R  )  =  (i  ), 
J  P  P  P 

and  -2(Ip)  =  1.  An  example  of  this  case  is  given  below. 

Example  4.9:  Instruction  I is  "Load  register  R^  from  the 

main  memory  location  (next  to  the  one  storing  the  opcode  of  instruction 

I.),"  and  instruction  I  is  "Load  register  R  from  the  main  memory 
J  K  i. 

location."  □ 

Procedure  4.8: 

This  procedure  is  applicable  for  case  B(1.2.2.2). 

It  generates  tests  to  detect  fault  f(I./l.)  when  2(1.)  =  2(1  )  =  1, 

J  K  J  K 

and  during  the  execution  of  1^  and  1^  the  results  of  the  operations  are 
stored  in  different  registers. 

Step  1:  Store  OPERAND  1  in  register  R  and  proper  operands  in  S (I . ) 

p  j 

such  that  when  I ^  is  executed  RESULT  1  is  produced  in  R^, 
and  RESULT  1  f  OPERAND  1 . 

Step  2:  Read  out  register  R  by  executing  READ  (R  )  »  (i  ) . 

P  P  P 

/Expected  output  data  =  OPERAND  1/ 

Step  3:  Repeat  step  2. 

Step  4:  Execute  I ^ . 
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Step  5:  Read  out  register  R  by  executing  READ  (R  )  =  (i  )  • 
—  P  P  P 

/Expected  output  data  =  RESULT  1  #  OPERAND  1/ 


Theorem  4.7:  Procedure  4.8  detects  f(I./I  )  in  case  B(1.2.2.2). 

J  K 

The  proof  of  this  theorem  follows  the  proof  of  Theorem  4.6 

closely  and  will  not  be  repeated  here. 

4 . 3 . 3 . 2  .  Test  Generation  for  f(I^. /I^)  when  i(l  )  =  2 

This  case  is  referred  to  as  case  B(2)  and  is  divided  into  two 

subcases  depending  on  whether  or  not  D(I.)  =  D(I  ) . 

J  h 

Case  B(2 ■ 1) :  D(I.)  ?  D(I,  )  .  In  this  case  under  the  faula 

j  k. 

f(I./l.),  the  contents  of  D(I.)  remain  unchanged  as  they  would  remain 

j  K  J 

under  the  fault  f(I  J<b) .  Hence,  the  procedure  for  this  case  is  the 
same  as  Procedure  4.4.  Furthermore,  using  arguments  similar  to  those  in 
the  proof  of  Theorem  4.2,  it  can  be  proved  that  Procedure  4.4  detects 
f(Ij/Ik)  in  this  case. 

Case  B(2 .2) :  D(I.)  =  0(1,,).'  This  case  is  not  treated  here  because 

J  K 

all  the  details  considered  for  case  C(3.1)  in  Section  4. 3. 4. 3  apply  to  this 

case  .  i  Procedure  4 . 17  used  to  detect  f(I^/lj+I^)  in  case  C (3 . 1 )  (refer  to 

Table  4.3)  can  detect  f(I  /I  )  in  case  B(2.2)  discussed  here.  This  will 

be  pointed  out  in  the  proof  of  Theorem  4.16. 

4. 3- 3. 3.  Test  Generation  for  ffl./l.  )  When  1(1.)  :g  K  2  3 

J  K  J 

This  case  is  referred  to  as  case  BC3') .  Note  that  1^  belongs 
to  class  T  according  to  our  assumption  in  Section  4.3.1.  This  case 
can  be  further  divided  into  two  subcases  depending  on  whether  or  not 
D(I.)  =  D(Ife)  ■ 
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Case  B(3.1):  D(I.)  /  D(I,  ) .  In  this  case  under  the  fault 

J  R 

f(I./I,)»  the  contents  of  D(I.)  remain  unchanged  as  under  the  fault 
J  K  J 

f  (I . /0) -  Hence,  the  procedures  for  this  case  will  be  the  same  as 

Procedures  4.4  and  4.5.  Note  that  Procedure  4.4  is  applied  in  case  A(3.1) 

and  Procedure  4.5  is  applied  in  case  A(3.2).  Using  arguments  similar 

to  those  in  the  proofs  of  Theorems  4.3  and  4.4,  it  can  be  proved  that 

Procedures  4.4  and  4.5  detect  f(I./l,  )  in  this  case. 

J  k' 

Case  B(3 .2) :  D(I.)  =  D(I  ) .  Note  that  2(1.)  =  2(1  )  =  K,  and 

J  K  j  k 

2(D(I.))  =  -2(D(I,))  =  K*l.  Therefore  no  instruction  in  the  READ  (D(I.)) 

J  K  j 

sequence  can  have  a  label  greater  than  K-l.  This  case  is  illustrated  in 

Figure  4.4.  Note  that  READ  (D(I.))  =  (i  ,  I  ,  I  >  where 

2  PK- 1  pK-2  P1 

2(1  )  =»  i,  for  1  ^  i  s  K-l.  Depending  on  2(S(I  ))  the  case  can  be  further 

pi  K 

divided  into  two  subcases.  Case  B(3.2.1)  applies  when  2(S(Ik>)  <  K,  and 

case  B(3 .2.2)  applies  when  2(S(I  ))  =  K-  Note  that  2(s(I  ))  ¥  K, 

since  2(1,  )  ”  K  and  I,  belongs  to  class  T.  (Also  refer  to  the  labeling 

algorithm  given  in  Section  4.1.) 

Case  B(3 .2 . 1) :  £(S(Ik))  <  K-  In  this  case  the  instruction  1^ 

does  not  belong  to  the  READ  (Sd^))  sequence.  (This  will  be  proved  in 

the  proof  of  Theorem  4.3) 

Procedure  4.9: 

This  procedure  is  applicable  for  case  B(3.2.1).  It  generates 
tests  to  detect  fault  f(I./I  )  when  2(1.)  =  2(1  )  =  K  2  3,  D(I.)  =  D(I.  ), 

J  K  J  K  j  k 

and  2(S(Ik))  <  K- 

Step  1:  Store  OPERAND  1  in  S(I.)  and  OPERAND  2  in  S(I  )  such  that 

J  k 

OPERAND  1  t  OPERAND  2  . 


Step  2 :  Execute  I .  . 


S(Ij) — - 


Figure  4.4.  Illustrating  case  B (3 .2 )  in  Section  4. 3. 3. 3. 
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Step  3:  Read  out  S(I^)  by  executing  READ  (S(I^)). 


/Expected  output  data  =  OPERAND  2/ 

Step  4:  Read  out  D(I^)  by  executing  READ  (0(1^)). 
/Expected  output  data  =  OPERAND  1/ 


Theorem  4.8:  Procedure  4.9  detects  f(I./I  )  in  case  B(3.2.1). 

j  K 

Proof:  Note  that  4(1^)  =  K.  Since  4(S(Ik))  <  K,  no  instruction  in 

the  READ  (S(I^))  sequence  can  have  a  label  greater  than  K-l,  implying  that 

1^  SE  READ  (S(Ik>).  Therefore  READ  (S(I^))  reads  out  S(I^)  without 

routing  it  through  D(I.)  =  D(I,  ). 

J  K 

When  the  microprocessor  under  test  executes  this  procedure,  it 
has  already  executed  the  tests  required  to  detect  f (I  /0) ,  f (I  /I  ), 

p  p  q 

and  f(I  /I  +1  )  where  1  ^  4(1  ),  4(1  )  s  K-l,  and  f(I  /I  +1  )  where 
ppq  pq  vvw 

1  £  4(i^)  5  K-l  and  j0 (Iw)  =  K.  Therefore,  when  the  microprocessor  under 

test  executes  this  procedure  it  has  already  been  checked  that  the 

READ  (D (I . ) )  and  READ  (S(I, ))  sequences  correctly  read  out  D(I.)  and  S  (I, ), 

J  k  j  k 

respectively.  (Recall  that  no  instruction  in  the  READ  (D(Ij))  or 

READ  (3(1^))  sequences  can  have  a  label  greater  than  K-l.)  Moreover, 

after  the  execution  of  these  sequences  the  contents  of  D(I.)  and  S(I  ) 

J  k 

do  not  alter. 

In  step  2,  I j  is  executed  and  it  is  expected  to  produce  OPERAND  1 

in  D(I.)-  If  f(I./l  )  is  present,  OPERAND  2  will  be  produced  in  D(I.) 

J  j  k  j 

instead  of  OPERAND  1,  provided  S(I^)  really  contained  OPERAND  2  when  l. 
is  executed.  In  this  situation  the  fault  will  be  detected  in  step  4. 

(Note  that  in  step  3,  READ  (S(I,  ))  reads  out  S(I,  )  without  routing  it 

tC  tC 

through  D(I.)  =  D(I,).)  On  the  other  hand,  due  to  faults  involved  in  the 
J  k 

instructions  used  to  write  data  in  5(1^),  OPERAND  2  may  not  be  stored 
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in  S(Ik) ;  in  Chis  case  the  fault  will  be  detected  in  step  3  itself.  O 

Case  B(3.2.2) :  2(S(Ik))  =  K-  In  this  case  I  €  READ  (S(I  )). 

Procedure  4.9  used  for  case  B(3.2.1)  cannot  be  used  in  this  case 

because  in  step  3,  READ  (S(Ik))  will  read  out  S (Ik)  by  routing  it  through 

D(I.)  =  D(I  ),  destroying  its  contents. 

J  R 

Procedure  4.10: 

This  procedure  is  applicable  for  case  B(3.2.2).  It 
generates  tests  to  detect  fault  f(I./I,  )  when  2(1.)  =  2(1  )  =  K  ^  3, 

j  ic  j  K 

D(I j )  *  D(Ik),  and  2(S(Ik)*)  =  K. 

Step  1:  Store  OPERAND  1  in  S(I.)  and  OPERAND  2  in  S (I  )  such  that 

J  R 

OPERAND  1  +  OPERAND  2  . 

Step  2:  For  i  «-  1  TO  K  DO 
BEGIN 

Execute  I  ; 

Read  out  D(I^)  by  executing  READ  (D(I^)). 

/Expected  output  data  =  OPERAND  1/ 

END 

Step  3:  Execute  Ik> 

Step  4:  Read  out  D(I,  )  by  executing  READ  (D(I,  ))  =  READ  (D(I.)). 

K  J 

/Expected  output  data  =  OPERAND  2/  — 

Theorem  4.9:  Procedure  4.10  detects  f(I./l,  )  in  case  B(3.2.2). 

j  K 

Proof:  In  step  2  of  Procedure  4.10,  register  D(I^)  is  read 

out  by  executing  READ  (D ( I . ) )  =  \I  ,  I  ,  . . . ,  I_  / .  (Refer  to 

J  K-l  PK-2  *1 

Figure  4.4.)  Recall  that  2(1.)  =  2(1,)  =  K,  and  2(1  )  =  i,  for 

J  K  Pj_ 

1  ^  i  s  K-l.  When  the  microprocessor  under  test  executes  this  procedure, 


J 
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it  has  already  been  checked  that  f(I  /<t>) ,  f(I  /I  )  and  f  (I  /I  +1  )  do 

P  P  q  P  P  q 


not  exist,  where  1  ^  ,2(1  ),  -2(1  )  5  K-l.  Therefore,  D(I.)  can  be  correctly 

p  q  j 


read  out  by  executing  READ  (0(1^)) 


If  OPERAND  2  is  really  stored  in  S(I^)  in  step  1,  the  fault 


f(Ij/l^)  will  be  detected  when  D(Ij)  is  read  out  during  the  first 


iteration  of  step  2,  since  OPERAND  2  will  be  read  out  instead  of  OPERAND  1. 
On  the  other  hand,  due  to  the  faults  involved  in  instructions  used  to 


write  data  in  S(I^),  OPERAND  1  may  have  been  stored  in  S(I^).  In  this 


situation  the  fault  will  not  be  detected  during  the  first  iteration  of 
step  2.  We  now  prove  that  it  is  necessary  and  sufficient  to  repeat  the 


loop  in  step  2  K  times,  where  |R£AD  (D (I j ) ) |  =  K-l. 


Sufficiency:  So  far  the  microprocessor  under  test  has  not 


executed  the  tests  to  detect  f(I  /I  +1  ),  where  1  ^  -2(1  )  £  K-l  and 

V  V  W  V 


K+ 1  s  -2(1  )  5  K  .  If  a  fault  f(I  /I  +  I  ,  )  is  present,  where 
w  max  Pi  Pi  Pi 


I  €  READ  (D  (I . ) )  and  K+ 1  s  1(1  ,)  s  K  ,  it  has  yet  not  been  detected. 
Pj_  J  Pt  ma* 


Consider  a  sequence  of  instructions  (i  ,  ,  I  ,  ,  . . . ,  I  , )  where  I  , 

PK-1  PK-2  P1  Pi 


belongs  to  this  sequence  if  and  only  if  the  fault  f(I  /I  +  I  ,)  is 

Pi  Pi  pi 


present,  for  1  ^  i  ^  K-l.  Since  K  +  l  ^  -2(1  ,)  ^  K  and  K  s  3 ,  I  , 

p.  max  p 

i 


belongs  to  class  T  according  to  our  assumption  in  Section  4.3.1. 


Therefore,  we  designate  the  sequence  (i  ,  ,  I  ,  ,  . . . ,  I  , )  as  the  T 


PK-1  PK-2 


sequence  a' .  Note  that  there  are  at  most  K-l  instructions  in  cr '  .  Thus 
when  the  READ  (D(Ij))  sequence  is  executed  in  step  2,  the  T  sequence  <?' 
is  also  executed  in  addition.  Consider  the  register  which  is  1-step 


transferrable  to  S(I^)  under  the  T  sequence  a'.  The  contents  of  this 


register  before  the  execution  of  READ  (D (I  , ) )  in  the  first  iteration  of 


j' 


step  2  will  become  the  final  contents  of  S(I^)  at  the  end  of  the  first 


:  J 


iteration  of  step  2.  This  may  alter  the  contents  of  S(I^). 

During  the  first  K-l  iterations  of  step  2  READ  (D (I j ) )  is 
executed  K-l  times,  and  so  is  the  T  sequence  a'.  If  register  S(I^) 
contains  OPERAND  1  at  the  end  of  each  of  i  iterations  of  step  2, 

(i.e.,  at  the  end  of  each  of  i  executions  of  the  T  sequence  a’,  for 
1  ^  i  ^  K-l),  then  by  Corollary  2.3,  at  the  end  of  the  K*"*1  execution  of 
the  T  sequence  cr1  ,  S(I^)  will  contain  OPERAND  1.  Recall  that  there  are 
at  most  K-l  instructions  in  the  T  sequence  o' .  If  this  is  so,  the 
fault  will  be  detected  in  step  4  as  OPERAND  1  #  OPERAND  2  will  be  read 
out . 

On  the  other  hand,  if  at  the  end  of  any  of  the  first  K-l  iterations 
of  step  2,  S(Ik)  contains  data  different  from  OPERAND  1,  the  fault  will  be 
detected  in  the  next  iteration  of  step  2  when  0(1^)  is  read  out  by 
executing  READ  (D(I^)),  as  the  output  data  will  be  different  from  OPERAND  1- 

Necessity:  Let  the  loop  in  step  2  be  repeated  only  p  times, 
where  1  5  p  ^  K-l.  (Recall  that  K.s  3,)  Consider  the  register  which  is 
p-step  transferrable  to  S(I^)  under  the  T  sequence  o'.  Since  there  can 
be  as  many  as  K-l  instructions  in  o' ,  such  a  register  can  exist  (from 
Theorem  2.1).  If  this  register  contains  OPERAND  2 ,  and  S(I^_)  and  each 
register  which  is  j-step  transferrable  to  S(I,  )  (1  ^  j  s  p-1)  under  the 
T  sequence  a'  contains  OPERAND  1  at  the  beginning  of  the  first  iteration 
of  the  loop,  then  the  contents  of  S(I^)  will  be  equal  to  OPERAND  1  at  the 
end  of  each  of  i  iterations  of  the  loop,  for  1  ^  i  ^  p-1,  and  they  will 
become  OPERAND  2  at  the  end  of  the  pC^  iteration  of  the  loop.  (Refer  to 


Corollary  2.1.) 


Therefore,  OPERAND  1  will  be  read  out  during  each  of  p  iterations 


of  the  loop  in  step  2,  and  OPERAND  2  will  be  read  out  in  step  4,  as  expected. 
Thus  the  fault  may  remain  undetected  if  the  loop  in  step  2  is  repeated  less 
than  K  times .  □ 


4.3.4.  Test  Generation  for  f(I^/l^+I^) 


The  details  of  test  generation  depend  on  2(1.)  and  2(1  ). 

J  k 

We  consider  six  cases,  namely,  case  C(l)  through  case  C(6).  The  suffix  C 

is  used  to  denote  that  a  case  belongs  to  the  details  of  test  generation 

for  f(I./I.+I,  ).  These  cases  are  divided  into  subcases  which  are  listed 
J  J  k 

in  Table  4.3.  For  each  case,  the  table  gives  which  test  generation 
procedure  is  applicable  and  which  theorem  proves  the  fault  coverage. 

4. 3. 4.1.  Test  Generation  for  f (I  . /I  .-*T.  )  When  2(1.)  »  2(1  )  =  l 

J  J  k  j  k 

This  case  is  referred  to  as  case  C(l) .  As  in  the  case  B(1.2),  many 

faults  in  this  case  would  be  readily  detected  because  I.  and  I,  have  the 

j  k 

highest  observability.  This  case  can  be  divided  into  two  subcases,  namely 
case  C(l.l)  and  case  C(1.2),  exactly  in  the  same  way  case  B ( 1 . 2 )  was  divided 
into  case  B(1.2.1)  and  case  B(1.2.2).  (Refer  to  Section  4.3.3. 1.)  The  tests 
generated  by  Procedure  4.11  for  case  C(l.l)  are  to  be  applied  before  those 
generated  by  procedures  for  case  C(1.2). 

Case  C(l.l):  During  the  execution  of  1^  and  1^  the  results  of 
the  operation  performed  are  "read  out". 

Procedure  4.11: 

This  procedure  is  applicable  for  case  C(l.l).  It  generates 

tests  to  detect  f(I./l.+I,  )  when  2(1.)  =  2(1,  )  =  1  and  during  the  execution 
j  j  k  y  k 

of  I.  and  I,  the  results  of  the  operations  are  read  out. 
j  k 


I 


Table  4.3  (continued).  Cases  for  the  details  of  test  generation  for  detecting  f(I./l.+I 


Fault  coverage  can  be  proved  by  following  arguments  similar  to  those  in  the  proof  of 
the  theorem  (marked  with  t). 
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Step  1:  If  possible,  store  proper  operands  in  S  (I  . )  and  S(I.  )  such  that 

J  '  k 

when  I .  is  executed  RESULT  1  is  read  out  and  when  I,  is  executed 
1  k 

RESULT  2  is  read  out,  and  (RESULT  1  )  V  (RESULT  2)  +  (RESULT  1)  . 
/V  denotes  the  bit-wise  logical  OR  function/ 


Step  2 


Step  3 


Step  4 


Execute  1^.  /Expected  output  data  =  RESULT  1  / 

Execute  1^.  /Expected  output  data  =  RESULT  2  / 

If  possible,  store  proper  operands  in  S  (I . )  and  S(I  )  such  that 

J  k 

when  I .  is  executed  RESULT  3  is  read  out  and  when  I,  is  executed 
J  k 

RESULT  4  is  read  out,  and  (RESULT  3  )  A  (RESULT  4)  t  (RESULT  3). 

/A  denotes  the  bit-wise  logical  AND  function/ 

Step  5:  Execute  I ^ .  /Expected  output  data  =  RESULT  3/ 

Step  6 :  Execute  1^.  /Expected  output  data  =  RESULT  4/  i— 


The  underlined  phrase  "if  possible"  in  steps  1  and  4  may 
come  as  a  surprise.  However,  it  may  not  be  possible  to  satisfy  conditions 
given  in  both  the  steps  due  to  the  nature  of  the  operations  performed 
under  the  instructions  1^  and  1^.  The  following  example  illustrates  the 
point . 


Example  4 ■  10 :  Let  instruction  1^  be  "Store  the  contents  of 
register  R^  into  the  main  memory  location  (next  to  the  one  containing 
the  opcode  of  instruction  1^),"  and  instruction  1^  be  "Perform  the  logical 
AND  of  the  contents  of  registers  R^  and  R^  and  store  the  result  into  the 
main  memory  location."  The  requirement  in  step  4  of  Procedure  4.11  can  be 
satisfied  by  storing  a  ONE  in  R^  and  a  ZERO  in  R?  so  that  under  I ^  a  ONE 
is  read  out  and  under  1^  a  ZERO  is  read  out,  and  (ONE  A  ZERO)  =  ZERO  #  ONE. 
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On  the  other  hand,  no  operands  would  satisfy  the  requirement 
in  step  1.  This  can  be  easily  proved.  Let  OPERAND  1  and  OPERAND  2  be 
stored  in  R^  and  R^  respectively.  I  will  read  out  RESULT  1  =  OPERAND  1 
and  Ik  will  read  out  RESULT  2  =  (OPERAND  1)  A  (OPERAND  2)  .  If  f(l7l  +1^ 
is  present,  then  as  illustrated  in  Example  3.2,  (RESULT  1)  *  (RESULT2) 
would  be  read  out,  where  *  denotes  the  bit-wise  logical  AND  or  OR  function 
depending  on  technology.  In  this  situation,  if  *  is  the  OR  function,  I 
would  read  out  (RESULT  1)  V  (RESULT  2)  =  (OPERAND  1)  >  ((OPERAND  1)  A 

(0PERAND2))  =  OPERAND  1  =  RESULT  1,  as  expected.  Thus,  the  fault 

f(I./l.+I,  )  is  an  undetectable  fault.  C 

J  J  k 

Theorem  4 ■ 10 :  Procedure  4.11  detects  all  detectable 

f(I./I.+I,  )  faults  in  case  C  ( 1  - 1 )  - 
J  J  f- 

Proof :  If  the  proper  operands  as  required  by  the  condition  in 
step  1  are  really  stored  in  S(Ik),  and  f(I  /I  +1^)  causes  the  actual 
result  read  out  under  instruction  I j  to  be  the  bit-wise  logical  OR 
combination  of  RESULT  1  and  RESULT  2 ,  the  fault  will  be  detected  in  step  2 

as  (RESULT  1)  V  (RESULT  2  )  #  RESULT  1  will  be  read  out.  On  the  other  hand, 


under  faults  involved  in  the  instructions  used  to  store  data  in  S(Ik), 

wrong  operands  may  have  been  stored  in  S(Ik)  in  step  1.  In  this  situation 

the  fault  will  be  detected  not  in  step  2  but  in  step  3  when  1^  is  executed. 

(Recall  the  fault  model  in  Section  3.2;  if  f(I./I.+I  )  exists,  I,  is 

J  J  K  K 

correctly  executed.)  Steps  4,  5,  and  6  detect  the  fault  if  f(I  /Ij+I^) 

causes  the  actual  result  read  out  under  instruction  I.  to  be  the  bit-wise 

J 


logical  AND  combination  of  RESULT  1  and  RESULT  2  . 
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Case  C(1.2) :  During  the  execution  of  instructions  I ^  and  1^ 
the  results  of  the  operations  performed  are  stored  in  registers.  (The 
results  are  not  read  out  as  in  case  C(l.l).)  This  case  is  identical  to 
case  B(1.2.2),  and  all  the  points  illustrated  in  Example  4.7  do  apply 
here  too.  Depending  on  whether  the  results  of  I ^  and  are  stored  in 
the  same  or  different  registers  we  divide  this  case  into  two  subcases, 
namely,  case  C(1.2.1)  and  case  C(1.2.2),  exactly  in  the  same  way 
case  B(1.2.1)  was  divided  into  case  B(1.2.1.1)  and  case  B(1.2.1.2). 

Case  C(1.2 . 1) :  The  results  produced  by  executing  instructions 
I.  and  I  are  stored  in  the  same  register.  Let  this  register  be 

J  K 

designated  as  R  ;  furthermore  let  READ  (R  )  =  (i  ) .  Note  that  2(1  )  =  1. 

P  P  P  P 

(Refer  to  Example  4.8.)  In  this  case  we  follow  Procedure  4.7  given  for 
case  B(1.2.2.1),  except  for  two  modifications: 

1.  In  step  1  of  Procedure  4.7,  RESULT  1  and  RESULT  2  should 
satisfy  the  condition  (RESULT  1)  V  (RESULT  2  )  £  RESULT  1. 

2.  Step  1  through  step  5  of  Procedure  4.7  are  repeated,  and  RESULT  1 
and  RESULT  2  should  satisfy  the  condition  (RESULT  1)  A  (RESULT2)  #  RESULT1. 

It  can  be  easily  proved  that  the  procedure  detects  f(Ij/l^+I^) 
in  this  case  by  following  the  similar  arguments  used  in  the  proofs  of 
Theorems  4.6  and  4.10. 

Case  C (1 . 2 . 2) :  The  results  produced  by  executing  instructions 

Ij  and  1,^  are  stored  in  different  registers.  Let  the  result  produced  by 

I,  be  stored  in  register  R  .  Furthermore,  let  READ  (R  )  =  (i  ) .  Note 
k  P  P  P 

that  i  (Ip)  =  1. 


116 


Procedure  4.12; 


This  procedure  is  applicable  for  case  C(1.2.2).  It 

generates  tests  to  detect  fault  f(I./I.+I  )  when  2(1.)  =  2(1,  )  =  1,  and 

3  3  R  3  k 

during  the  execution  of  1^  and  1^  the  results  of  the  operations  are  stored 
in  different  registers. 

Step  1;  Store  OPERAND  1  in  register  and  proper  operands  in  S (1^)  such  that 

when  I,  is  executed  RESULT  1  is  stored  in  R  and  RESULT  1  ^  OPERAND  1. 
k  p 

Step  2:  Read  out  register  R  by  executing  READ  (R  )  =  (i  )  . 

P  P  P 


Step  3 


Step  4 


Step  5 


/Expected  output  data  =  OPERAND  1  / 

Repeat  step  2. 

Execute  I . . 

3 

Read  out  register  R  by  executing  READ  (R  )  =  (i  ) 
P  P  P 

/Expected  output  data  =  OPERAND  1  *  RESULT  1/ 


Theorem  4.11:  Procedure  4.12  detects  f(I./l.+  I.  )  in 
-  3  3  k 


case  C(1.2 .2) . 


The  proof  of  this  theorem  follows  closely  that  of  Theorem  4.6 


and  will  not  be  repeated  here. 


4. 3. 4. 2.  Test  Generation  for  f(I./l.+I,  )  When  2(1.)  =  1 

- i-3_3_k^ - - 

and  2(1  )  =  2 

K 

This  case  is  referred  to  as  case  C(2) .  We  divide  this  case 

into  various  subcases,  namely,  case  C(2.1)  through  case  C(2.4),  depending 

on  whether  D(I,  )  c  S(I.)  and  whether  during  the  execution  of  I.  the  result 
R  3  3 

of  the  operation  performed  under  I ^  is  read  out.  Tests  generated  for 
case  C(2.1)  and  case  C(2.2)  are  to  be  applied  before  those  for  case  C(2.3) 
and  case  C (2 .4) . 
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Case  C (2 ■ 1) :  D(I,)  Q  S(I.),  and  the  result  of  the  operation 

R  J 

performed  under  I ^  is  read  out  during  its  execution.  An  example  of  this 
case  is  given  below. 

Example  4.11:  Instruction  1^  is  "Push  the  contents  of  the 
accumulator  on  the  top  of  a  LIFO  stack  maintained  in  the  main  memory," 
and  instruction  I  is  "Transfer  the  contents  of  register  R  to  the 
accumulator."  In  general,  1^  may  perform  some  operation  on  its  operands 
and  then  read  out  the  result.  G 

Procedure  4.13: 

This  procedure  is  applicable  for  case  C(2.1).  It  generates 

tests  to  detect  f(I./l.+I  )  when  2(1.)  =  1,  2(1  )  =  2,  D(I,  )  c  S(I.),  and 
1  1  k  j  k  k  j 

the  result  of  the  operation  performed  under  1^  is  read  out  during  its 
execution. 


Step  1:  Store  proper  operands  in  S(I^)  such  that  when  1^  is  executed 

RESULT  1  is  read  out.  Store  proper  operands  in  S(I^)  such  that 
when  1^  is  executed,  it  changes  the  contents  of  0(1^)  so  that  if 


Step  2 


Step  3 


Step  4 


Step  5 


I.  is  executed  after  I,  ,  RESULT  2  t  RESULT  1  will  be  read  out. 
J  k 

Execute  I  .  /Expected  output  data  =  RESULT  1  / 

Repeat  step  2.  /Expected  output  data  =  RESULT  1  #  RESULT  2  / 

Execute  I.  . 

k 

Execute  I  .  /Expected  output  data  =  RESULT  2  / 


Theorem  4.12:  Procedure  4.13  detects  f(I./I.+I,  )  in  case  C(2.1). 

-  j  j  k 

Proof :  If  the  proper  operands  as  required  in  step  1  are  really 
stored  in  S(I^)  the  fault  will  be  detected  in  step  3,  because  RESULT  2  will 
be  read  out  instead  of  RESULT  1.  If  proper  operands  are  not  stored  in 


S(I,  )  due  to  the  faults  in  instructions  used  to  write  data  in  S (I  ) ,  the 

iC  K 
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fault  may  not  be  detected  in  step  3,  but  it  will  be  detected  in  step  5 

because  the  output  data  will  then  be  different  from  RESULT  2 .  □ 

Case  C(2 .2) :  D(I,  )  i  S(I.)  and  the  result  of  the  operation 
k  J 

performed  under  1^  is  read  out  during  its  execution. 

Procedure  4.14: 

This  procedure  is  applicable  for  case  C(2.2).  It  generates 
tests  to  detect  fault  f(I./l.+I  )  when  4(1.)  =  1,  4(1  )  =  2,  D(I  )  <t  S(I.), 

J  J  K  j  K  K  J 

and  the  result  of  the  operation  performed  under  I ^  is  read  out  during  its 
execution. 

Step  1:  Store  proper  operands  in  S(I^)  and  OPERAND  1  in  D/I^.)  such  that 
when  1^  is  executed  it  produces  RESULT  1  £  OPERAND  1  in  D(I^). 

Step  2 :  Execute  I ^  . 

Step  3:  Read  out  D/I^)  by  executing  READ  (D/I^)). 

/Expected  output  data  =  OPERAND  1  / 


Step  4 


Step  5 


Step  6 


If  4(S(I,))  ^  2  then  repeat  steps  2  and  3  else  go  to  step  5. 

Execute  I,  . 

k 

Read  out  D/I^)  by  executing  READ  (0(1^)). 

/Expected  output  data  =  RESULT  1  £  OPERAND  1  / 


Theorem  4.13:  Procedure  4.14  detects  f(I./l.+I.  )  in  case  0(2.2). 

-  j  j  k 

Proof :  If  the  proper  operands  as  required  in  step  1  are  really 

stored  in  S (I,  )  the  fault  f(I./l.+I.)  will  be  detected  in  step  3  because 
k  J  J  k 

RESULT  1  #  OPERAND  1  will  be  read  out.  On  the  other  hand,  if  proper 


operands  are  not  stored  in  S/I^)  because  of  faults  in  the  instructions 

used  to  store  data  in  S(I^),  OPERAND  1  may  be  produced  in  D/I^)  when  I  is 

executed.  In  this  situation  step  3  will  not  detect  the  fault  f(I./I.+I,  ). 

J  J  k 

The  necessity  for  step  4  is  now  explained. 


At  this  stage  the  microprocessor  under  test  has  not  executed 
the  tests  to  detect  f(I  /I  +1  )  where  1(1  )  =  1  and  £(I  )  £  3.  If 

ppq  p  q 

f(I  /I  +1  )  is  present  and  D(I  )  *  S(I.  )  (requiring  i(S(I,  ))  ^  2),  then 
ppq  q  k  k 

the  execution  of  READ  (D(I^))  in  step  3  may  cause  a  change  in  the 

contents  of  S (I,  )  due  to  the  additional  execution  of  I  .  This  will  be 
k  q 

detected  in  step  4  as  the  output  data  will  be  different  from  OPERAND  1. 

On  the  other  hand,  if  the  contents  of  S(I^)  remain  unchanged  after  step  3 
they  will  remain  unchanged  after  step  4  also.  In  this  situation  the 
fault  will  be  detected  in  step  6  as  the  output  data  will  be  different 
from  RESULT  1 .  □ 


Case  C(2.3):  The  results  produced  during  the  execution  of 


1^  and  1^  are  stored  in  the  same  register.  (The  result  of  the  operation 


performed  under  I  is  not  read  out,  as  in  case  C(2.1)  or  case  C(2.2).) 


Let  this  register  be  designated  as  R  ;  furthermore  let  READ  (R  )  =  (i  ). 

P  P  P 


Note  that  i(I^)  =  !•  (This  is  consistent  with  our  discussion  in 


Example  4.7.) 

Procedure  4.15: 

This  procedure  is  applicable  for  case  C(2.3).  It  generates 


tests  to  detect  fault  f(I./l.+I,  )  when  1(1.)  =  1,  -2(1,  )  =  2,  and  the  results 

^  j  j  k  j  k  ’ 


produced  during  the  execution  of  I.  and  I  are  stored  in  the  same  register 

J 


designated  as  R  . 

P 


Step  1:  If  possible,  store  proper  operands  in  S(I.)  and  S (I  )  so  that 

J  k 


when  I .  is  executed  RESULT  1  is  produced  in  R  and  when  I,  is 
J  P  k 


executed  RESULT  2  is  produced  in  R  ,  and  (RESULT  1)  v  (RESULT  2) 

P 


*  (RESULT  1)  . 


Step  2 :  Execute  I . • 
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Step  3: 

Read  out  R^  by  executing  READ  (R^) 

11 

M** 

/Expected  output  data  =  RESULT  1  / 

Step  4: 

If  ^(S(I^))  s  2  then  repeat  steps 

2  and  3  else  go  to  step  5 

Step  5 : 

Execute  I.  • 
k 

Step  6: 

Read  out  R^  by  executing  READ  (R^) 

-  <1  >. 

P 

/Expected  output  data  =  RESULT  2  / 

Step  7: 

Repeat  step  1  with  the  change  that 

(RESULT  1)  A  (RESULT  2) 

#  (RESULT  1) . 

Step  8: 

Repeat  steps  2  through  6. 

Theorem  4.14:  Procedure  4.15  detects  f(I./l.+I,  )  in 

-  j  j  k 

case  C(2 .3) . 


The  proof  of  this  theorem  follows  closely  those  of  Theorems 

4.10  and  4.13,  and  hence  is  not  given. 

Case  C(2.4):  The  results  produced  during  the  execution  of 

I.  and  I  are  stored  in  different  registers. 

J  & 

Procedures  4.16: 

This  procedure  is  applicable  for  case  C(2.4).  It 

generates  tests  to  detect  fault  f(I./l.+l  )  when  -£(1.)  =  1,  -£(1.)  =  2, 

J  J  K  J  K 

and  the  results  produced  during  the  execution  of  I .  and  I,  are  stored  in 

J  K 

different  registers. 

Step  1:  If  possible,  store  proper  operands  in  S (1^)  and  OPERAND  1  in  D(I^) 
so  that  when  I  is  executed  RESULT  1  is  produced  in  D(I  )  and 

K  K 

RESULT  1  /  OPERAND  1 . 

Step  2:  Execute  I ^ . 
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Step  3:  Read  out  D(I^)  by  executing  READ  (D(I^))- 
/Expected  output  data  =  OPERAND  1  / 

Step  4 :  If  i(S(I^))  &  2  then  repeat  steps  2  and  3  else  go  to  step  5. 
Step  5:  Execute  I  . 

Step  6:  Read  out  D(I^)  by  executing  READ  (D(I^)). 

/Expected  output  data  =  RESULT  1/ 


(_ 


Theorem  4.15:  Procedure  4.16  detects  f(I./l.+I,  )  in 
-  j  j  k 

case  C (2 .4)  . 

The  proof  of  this  theorem  follows  the  arguments  given  in  the 
proof  of  Theorem  4.13,  and  hence  is  not  given. 


4. 3. 4. 3.  Test  Generation  for  f(I./I.+I,  )  When  1(1.)  =  1(1,  )  -  2 
- -  j  —  j  — .1  -  - 

This  case  is  referred  to  as  case  C/3)  and  is  divided  into  two 

subcases,  namely,  case  C ( 3 . 1 )  and  case  C ( 3 - 2 )  depending  on  whether  or 

not  D(I . )  =  D(I  ) . 

J  * 

Case  C (3 . 1) :  D(I.)  =  D(I,  )•  The  basic  requirement  of  test 

j  k 

generation  in  this  case  is  to  store  proper  operands  in  S(I.)  and  S(I,  )  such 

J  k 

that  if  I  is  executed  it  produces  an  x  €  [0,1}  in  some  bit  (say  the  p*-^1  bit) 

of  D(I.),  and  if  I  is  executed  it  produces  x  in  the  same  bit  of  D(I.). 

J  k  J 

When  Ij  is  executed  x  *  x  will  be  produced  in  the  p  bit  of  D(I^),  if 

f(Ij/l^+I^)  is  present.  (*  denotes  the  logic  AND  or  OR  function.)  Note 

that  x  *  x  #  x,  for  x  =  1  and  *  =  AND,  and  for  x  =  0  and  *  =  OR.  Thus, 

if  D (I j )  is  read  out  after  executing  I ^  the  fault  will  be  detected. 

If  D  (I  . )  £  S  (I . )  and  D(I.)  £  S(I.  ) ,  no  specific  data  need  to  be 
J  J  J  k 

stored  in  D(I.)  in  order  to  satisfy  this  requirement.  On  the  other  hand 

th 

if  D(I.)  =  S(I.)  or  D(I.)  =  S(I,  ),  in  order  to  produce  an  x  in  the  p 

J  J  J  k 


bit  of  D(I.)  when  1^  is  executed,  and  to  produce  x  in  the  pth  bit  D(I.) 
when  1^  is  executed,  it  may  be  required  that  some  specific  logic  value 
must  be  stored  in  the  p^  bit  of  D(I^.).  If  x  must  be  stored  in  the  pth 
bit  of  D(Ij),  the  situation  is  referred  to  as  "situation  A";  if  x  must 
be  stored  in  the  p^  bit  of  D(I^),  the  situation  is  referred  to  as 
"situation  B."  The  following  example  should  clarify  these  two  situations. 

Example  4 . 12 :  Suppose  instruction  1^  is  "Transfer  the  contents 
of  register  R^  to  register  R2>"  and  instruction  I  is  "Perform  the 
logical  AND  operation  on  the  contents  of  register  R2  and  R^ ,  and  store 
the  result  in  R2-"  Instructions  I  and  1^  are  represented  in  a  graph  in 
Figure  4.5.  We  must  store  x  =  0  in  the  pC^  bit  of  R^ ,  and  x  =  1  in  the 
pth  bit  of  both  R2  and  R^,  so  that  if  1^  is  executed  x  =  0  is  produced 
in  the  pC^  bit  of  R^ ,  and  if  1^  is  executed  x  =  1  is  produced  in  the  p1"*1 
bit  of  R^ •  Thus,  this  is  an  example  of  what  we  have  referred  to  as 
situation  B-  An  example  of  situation  A  can  be  easily  obtained  by  simply 


renaming  instruction  I.  as  I  ,  and  vice-versa,  and  letting  x  =  1. 

J  k 


We  now  present  two  subprocedures  to  be  used  in  these  two 
different  situations.  Followed  by  this  we  will  present  Procedure  4.17 
(which  is  a  test  generation  procedure  for  case  C (3 . 1 ) )  which  calls 
Subprocedure  A  (as  a  subroutine)  when  situation  A  is  present  and  calls 
Subprocedure  B  when  situation  B  is  present. 

Subprocedure  A: 

This  procedure  is  called  as  a  subroutine  by  Procedure  4.17 


when  situation  A  is  present. 
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Step  1: 
Step  2 : 

Step  3: 
Step  4: 
Step  5: 


Execute  I . • 

J 

Read  out  D(Ij)  by  executing  READ  (D (]_)). 

/The  bit  of  the  output  data  =  x/ 

If  -4(S(I^))  a  2  then  repeat  steps  1  and  2  else  go  to  step  4. 

Execute  I,  . 

k 

Read  out  D (I ^ )  by  executing  READ  (D(I.)). 

tH  — 

/The  p  bit  of  the  output  data  *  x/ 


Subprocedure  B: 

This  procedure  is  called  as  a  subroutine  by  Procedure  4.17 
when  situation  B  is  present. 


Step  1:  Execute  I 

Step  2:  Read  out  D(I^)  by  executing  READ  (0(1^)). 

/The  pth  bit  of  the  output  data  =  x/ 

Step  3:  If  4(S(Ik))  s  2  then  repeat  steps  1  and  2  else  go  to  step  4. 

Step  4:  Execute  I  . 

Step  5:  Read  out  D(I^)  by  executing  READ  (D(I^)). 
ttl 

/The  p  bit  of  the  output  data  =  x/  □ 

Procedure  4.17: 

This  procedure  is  applicable  for  case  C(3.1)  and 

case  B(2.2).  It  generates  tests  to  detect  fault  f(I./I.+I,  )  when  4(1.) 

J  J  k  j 

=  4(1  )  =  2  and  D(I.)  =  D(I,  ),  and  fault  f(I./I  )  when  4(1.)  =  4(1  )  =  2  and 

iC  J  iC  j  iC  J  K 

D(I.)  -  D(Ik). 

FOR  i  «-  1  TO  2  DO 


BEGIN 
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Step  1:  IF  i  =  1  THEN  x  «-  0  ELSE  x  <-  1. 

Step  2 :  If  possible,  store  proper  operands  in  S  (I  . )  and  S(I,  ) 

'  *  “  '  J  k 

such  that  if  I ^  is  executed  it  produces  x  in  some  bit 

(say  the  pC^  bit)  of  D(I.),  and  if  I  is  executed  it 

J  k 

produces  x  in  the  p  bit  of  D(Ij). 

Step  3:  If  step  2  requires  x  to  be  stored  in  the  p1"^1  bit  of  D(I^) 
then  execute  Subprocedure  A  else  execute  Subprocedure  B. 


END. 


Note  that  if  D(I.)  £  S(I.)  and  D(I.)  £  S(I  ).  then  as  mentioned 
J  J  J  k 

earlier  no  specific  data  need  to  be  stored  in  D(I^)  in  step  2  of 

Procedure  4.17.  Therefore  strictly  speaking  either  of  the  subprocedures 

could  be  called  in  step  3  when  D(I.)  £  S (I . )  and  D(I.)  £  S (I  ) . 

J  J  f  k 

Theorem  4.16:  Procedure  4.17  detects  f(I./I.+I,  )  in  case  C(3.1) 

-  j  j  k' 

as  well  as  f  (I  ./I.  )  in  case  B (2 .2)  . 

J  K 

Proof :  In  step  2,  proper  operands  are  chosen  in  S(I.)  and 


J 


th 


S (I.  )  to  produce  x  in  some  bit  (say  the  d  bit)  of  D (I . ) ,  if  I.  is 

k  j  J 

executed,  and  to  produce  x  in  the  same  bit  of  D(I.),  if  I  is  executed. 

j  k 

If  f(I./I.+I  )  is  present,  x  *  x  will  be  produced  in  the  p  bit  of  D(I.), 

J  J  k  ‘  j 

when  I.  is  executed.  If  f(I./I  )  is  present  x  will  be  produced  in  the 
J  J  k 

p  bit  of  D(Ij)-  The  first  iteration  of  the  FOR  loop  is  for  detecting  the 
fault  if  *  denotes  the  OR  function,  and  the  second  iteration  of  the  loop 
is  for  detecting  the  fault  if  *  denotes  the  AND  function. 

Without  loss  of  generality  we  assume  that  *  denotes  the  OR 
function  and  situation  A  exists.  Therefore  in  step  3,  Subprocedure  A  is 


executed  as  a  subroutine.  If  proper  operands  are  really  stored  in  S(I^) 


in  step  2  of  Procedure  4.17,  the  fault  will  be  detected  in  step  2  of 
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Subprocedure  A  when  D(I^)  is  read  out.  On  the  other  hand,  proper  operands 
may  not  be  stored  in  S(I  )  due  to  faults  involved  in  instructions  used  to 

rC 

write  data  in  S(I^).  In  this  case  the  fault  will  not  be  detected  in  step  2 

of  Subprocedure  A.  The  microprocessor  under  test  has  not  yet  executed 

tests  to  detect  f(I  /I  +1  )  where  2 (I  )  =  1  and  2(1  )  S3.  Therefore  the 
P  P  q  P  q 

execution  of  READ  (D(I.))  in  step  2  of  the  subprocedure  may  cause 

additional  execution  of  an  instruction  I  such  that  2(1  )  S3  and  D(I  ) 

q  q'  q  ' 

£  S(Ik) .  If  this  changes  the  contents  of  S  (Ik>  the  fault  may  be  detected 
in  step  3  of  the  subprocedure,  otherwise  it  will  be  detected  in  step  5. 
(Refer  to  the  details  of  the  proof  of  Theorem  4.13.)  G 

Case  G  (3  .2 ) :  D(l.)  t  D(I,  ).  In  this  case  we  follow  the 

J  k 

procedure  below. 

Procedure  4.18: 

This  procedure  is  applicable  for  case  C (3 . 2 ) .  It 
generates  tests  to  detect  fault  f(ldlj+Ik)  when  2(1.)  =  2(1^)  =  2  and 
Ddj)  *  D(Ik)  . 

Step  1:  Store  proper  operands  in  S (I  )  and  OPERAND  1  in  D(I  )  such 

K  rC 

that  when  Ik  is  executed  it  produces  RESULT  1  in  D(Ik), 
and  RESULT  1  j4  OPERAND  1.  If  2(S(Ik>)  =  1,  read  out  S(Ik>  by 
executing  READ  (S(Ik)). 

/To  make  sure  that  S(Ik)  contains  expected  operands/ 

Step  2 :  Execute  I ^  . 

Step  3:  Read  out  D(Ik)  by  executing  READ  (D(Ik>). 

/Expected  output  data  =  OPERAND  1  /  RESULT  1/ 


Step  4 :  If  2(S(Ik))  ^  2  then  repeat  steps  2  and  3  else  go  to  step  5. 


Step  5:  Execute  1^. 

Step  6:  Read  out  D(I^)  by  executing  READ  (D(I^)). 
/Expected  output  data  =  RESULT  1/ 


Theorem  4.17:  Procedure  4.18  detects  ffl./l.+I.  )  in 

-  j  j  k' 


case  C  (3 .2) . 


Proof :  We  will  give  only  the  sketch  of  the  proof  since  the 
basic  ideas  are  essentially  the  same  as  used  in  the  proofs  of  Theorem  4.10 


through  4.17.  If  proper  operands  are  really  stored  in  S/I^)  step  1 
the  fault  will  be  detected  in  step  3,  since  RESULT  1  will  be  read  out. 
On  the  other  hand,  if  proper  operands  are  not  stored  in  S(I^)  due  to 
faults  in  instructions  used  to  write  data  in  S (1^) ,  the  fault  will  be 
detected  either  in  step  1  (if  ^(S(I^))  =  1)  when  S(Ik)  is  read  out,  or 
in  step  4  or  6. 


4. 3. 4. 4.  Test  Generation  for  f (I ./I .+1,  )  When  2(1  . )  -  1(1,  )  =  K  s  3 
- -  J  — J  — kr - j 1 - Me - 


This  case  is  referred  to  as 


Note  that  according 


to  the  assumption  in  Section  4.3.1,  instructions  I.  and  I,  belong  to  class  T. 

J  k 

When  Che  microprocessor  executes  the  tests  to  detect  faults  f(I./l.+I.), 

J  J  k 

where  2(1 .)  =  2(1  )  =  K  2  3,  it  has  already  executed  the  tests  to  detect 
J  k 

faults  f(I  /I  +1  )  where  1  s  2(1  )  s  K-l  and  2 (I  )  ^  2;  in  particular  it  has 
p  p  q  p  q  ■ 

been  already  checked  that  the  execution  of  any  instruction  of  label  5  K*1 

will  not  give  rise  to  the  additional  execution  of  any  instruction  of  class  M- 

(Recall  our  assumption  in  Section  4.3.1  that  if  I  belongs  to  class  M, 

2(1 ^  ^2.)  We  divide  this  case  into  two  subcases  depending  on  wnether 

or  not  D(I  . )  =  D(I,  )  . 

J  k 


i 
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Case  C(4.1):  D(I.)  =  D(I  ).  Since  1(1.)  =  i( I  )  =  K, 

J  k  JR 

2(D(I^))  =  K-l.  This  case  is  illustrated  in  Figure  4.4,  where  depending 
on  i(S(I^))  this  case  can  be  further  divided  into  two  subcases. 

Case  C(4.1.1)  refers  to  £(S(I^))  <  K,  and  case  C(4.1.2)  refers  to  £(S(I,))  =  K- 

Note  that  £(S(I^))  ^  K,  since  4(1^)  =  K  and  I  €  class  T.  (Refer  to  the 

labeling  algorithm  given  in  Section  4.1.) 

Case  C (4 . 1 . 1) :  i(S(I^))  <  K-  In  this  case  we  follow  the 

procedure  below. 

Procedure  4.19: 

This  procedure  is  applicable  for  case  C(4.1.1).  It  generates 
tests  to  detect  fault  f(I./l.+I  )  when  1(1.)  =  1(1)  =  K  ^  3,  D(I.)  =  D(I  ), 

J  J  K  J  K  J  k 

and  l (S  (1^) )  <  K.  This  procedure  is  essentially  the  same  as  Procedure  4.9 

executed  twice,  with  the  following  modifications:  During  the  first 
execution  of  the  procedure,  in  Step  1  the  condition  to  be  satisfied  by 


f 


OPERAND  1  and  OPERAND  2  is  given  by  (OPERAND  1)  V  (OPERAND  2)  +  OPERAND  1, 


and  during  the  second  execution  of  the  procedure  the  condition  to  be 


satisfied  is  given  by  (OPERAND  1)  A  (OPERAND  2)  #  OPERAND  1 . 


Theorem  4.18: 


(4.1.1). 


Procedure  4.19  detects  f(I./l.+I,  )  in  case  C 

1  J  k 


Proof :  The  proof  of  this  theorem  parallels  closely  that  of 

Theorem  4.8.  We  will,  therefore,  stress  only  those  points  where  they  differ. 
In  step  2  of  Procedure  4.19,  1^  is  executed  and  it  is  expected  to  produce 
OPERAND  1  in  D(Ij).  If  f(l7l^+Ik)  exists,  (OPERAND  1)  *  (OPERAND  2 )  would 
be  produced  instead,  where  as  before  *  denotes  the  logical  AND  or  OR 
function,  provided  S(I^)  really  contained  OPERAND  2  when  1^  is  executed. 

In  this  case  the  fault  will  be  detected  in  step  4.  On  the  other  hand, 


J 
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due  to  the  faults  involved  in  the  instructions  used  to  write  data  in  S(I^), 
OPERAND  2  may  not  be  stored  in  S(I,  );  in  this  case  the  fault  will  be 
detected  in  step  3  itself.  “ 

Case  C (4 . 1 .2 ) :  2(S(I^))  =  K.  In  this  case  we  follow  Procedure 

4.10  twice,  with  the  same  modifications  given  for  case  C(4.1.1).  We  refer  to 
this  modified  Procedure  4.10  as  Procedure  4.20. 

Theorem  4.19:  Procedure  4.20  detects  ffl./I.+I.  )  in 

-  j  j  k 

case  C(4 . 1 .2 ) .  J 


The  proof  of  this  theorem  follows  closely  those  of  Theorem  4.9 
and  4.18,  and  hence  is  not  repeated  here. 

Case  0  04.2):  D(I^)  f  D(I^) .  Depending  on  2(S(I^))  this  case 

can  be  further  divided  into  two  subcases.  Case  C(4.2.1)  refers  to 
2(S(Ik))  <  K,  and  case  C(4.2.2)  refers  to  ^  (S  (1^) )  3  K-  Note  that 
4(S(Ik))  5*  K,  since  2(1^)  =  K  and  belongs  to  class  T. 


Case  C  (4 .2 . 1) :  2(s(I  ))  <  K.  In  this  case  we  use  the  procedure 


be  low . 


Procedure  4.21: 

This  procedure  is  applicable  for  case  C(4.2.1).  It 

generates  tests  to  detect  fault  f(I./I.+L  )  when  2(1.)  =  2(1  )  =  K  £  3, 

j  j  k  j  k 

D(I.)  5s  D(Ik>,  and  2(S(Ik))  <  K. 

Step  1:  Store  OPERAND  1  in  3(1^)  and  OPERAND  2  in  D(I  ),  such  that 
OPERAND  1  +  OPERAND  2  . 

Step  2 :  Read  out  S(Ik)  by  executing  READ  ( S (I ^ ) ) . 

/Expected  output  data  =  OPERAND  1/ 
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Step  3;  Execute  I ^ . 

Step  4 :  Read  out  D(Ik)  by  executing  READ  (D(I^)). 

/Expected  output  data  =  OPERAND  2  /  G 

Theorem  4.20:  Procedure  4.21  detects  f(I./l.+I.  )  in 

-  j  j  k 

case  C (4 .2 . 1) . 

Proof :  Since  ^(S(I^))  <  K,  no  instruction  in  the  READ  ( S  ) ) 
sequence  can  have  label  greater  than  K-l.  Also  4(d(I,  ))  *  K-l,  hence 

fC 

READ  (S(I,  ))  reads  out  S (I  )  without  routing  its  contents  through  D(I,  ). 

When  the  microprocessor  under  test  executes  this  procedure,  it  has 

already  executed  the  tests  to  detect  f(I  /0),  f(I  /I  ),  and  f(I  /I  +1  ) 

p  p  q  p  p  q 

where  1  s:  4(1),  4(1  )  s  K-l,  and  f (I  /I  +1  )  where  1  ^  4(1)  ^  K-l  and 

P  4  V  V  W  V 

4(Ir)  =  K.  Therefore,  in  step  2  of  this  procedure,  S (I  )  is  correctly 
W  k 

read  out  to  make  sure  that  it  stores  OPERAND  1,  and  it  continues  to  store 

OPERAND  1  after  READ  (S(I,  ))  is  executed.  In  step  3,  I.  is  executed.  If 

k  J 

f(I./I.+I.)  is  present,  OPERAND  1  will  be  stored  in  D(I  )  and  the  fault 
J  J  k  k 

will  be  detected  in  step  4.  G 

Case  C (4 .2  .2 ) :  £(S(I^))  =  K.  In  this  case  we  follow  the 

procedure  below. 

Procedure  4.22: 

This  procedure  is  applicable  for  case  C(4.2.2).  It 

generates  tests  to  detect  fault  f(I./l.+I,  )  when  4(1.)  =  1(1,  )  =  K  ^  3, 

j  2  k  j  '  k 

D(I.)  *  D(Ik),  and  4(s(Ik))  -  K. 

Step  1:  Store  OPERAND  1  in  S(Ik)  and  OPERAND  2  in  D(Ik>,  such  that 


OPERAND  1  #  OPERAND  2  . 
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Step  2  :  FOR  i  «-  1  TO  K  DO 
BEGIN 

Execute  1^ ; 

Read  out  0(1^)  by  executing  READ  (S(I^)). 
/Expected  output  data  =  OPERAND  2/ 

END 

Step  3:  Execute  I,  . 

Step  4:  Read  out  0(1^)  by  executing  READ  (D(I^)). 
/Expected  output  data  =  OPERAND  1 / 


Theorem  4.21:  Procedure  4.22  detects  f(I./I.+I,  )  in 
-  2  J  k' 

case  C(4.2 .2) .  _ 

The  proof  of  this  theorem  follows  very  closely  that  of  Theorem 
4.9  and  is  not  repeated  here. 


4. 3. 4. 5.  Test  Generation  for  fCl./l.+I,  )  When  1  £  4(i.)  ^  K, 

- ]  j  - 

l(Ik)  =  K+l,  and  K  a  2. 

This  case  is  referred  to  as  case  C(5).  Note  that  1^  belongs 
to  class  T  because  4(1,  )  =  K  +  l  and  K  2  2  .  Since  4(1.)  ^  K  and  4(1  )  =  K  +  l, 

K  J  K 

4(d(I.))  s  K-l  and  4(D(I,))  =  K;  hence  D(I.)  ^  D(I,  ).  We  divide  this  case 
J  R  J  ^ 

into  two  subcases  depending  on  whether  the  value  of  4(S(Ik))  is  less  than 
K  or  is  equal  to  K  or  K  +  l.  Note  that  it  cannot  be  greater  than  K  +  l 
because  4(1^)  =  K  +  l  and  1^  belongs  to  class  T. 

Case  C  (5  ■  1) :  4(S(Ik))  *  K-l.  We  follow  Procedure  4.21  in 

this  case.  Following  the  arguments  similar  to  those  given  in  the  proof 
of  Theorem  4.20,  it  can  be  proved  that  Procedure  4.21  also  detects 
f(I./I.+I,  )  in  case  C(5.1). 

J  J  k 
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Case  C(5 .2) :  i(S(I^))  =  K  or  K  +  l.  We  follow  Procedure  4.22 

in  this  case.  Following  the  arguments  similar  to  those  in  the  proof  of 

Theorem  4.9,  it  can  be  proved  that  Procedure  4.22  also  detects  f(I./l.+I,  ) 

J  J  K 

in  case  C (5  .2 ) . 


4 . 3 .4 . 6  .  Test  Generation  for  f  Cl  .  /I  .+1.  )  When  K  +  l  s  ^(1.)  ^  K  » 
- i — j  — j  — j  - nnax 

and  4(1^)  =  K. 

This  case  is  referred  to  as  case  C(6)  and  is  divided  into  three 

subcases  depending  on  the  value  of  K. 

Case  C(6.1):  2  5  ^(1.)  ^  K,  and  4(1,  )  =  1.  In  this  case  the 

j  ma  x  ic 

fauLt  f(I./I.+I  )  will  be  readily  detected  due  to  the  highest  observability 
J  J  k 

of  I  .  For  example,  during  the  execution  of  I,  ,  data  is  transmitted 

K  iC 

between  the  microprocessor  and  the  main  memory  or  an  I/O  device,  or  the 
logic  values  on  certain  status  pins  are  changed  (e.g.,  during  the 
execution  of  the  "Interrupt  enable"  instruction).  Such  is  not  the  case 
during  the  execution  of  1^,  therefore  f(I_./lj+I^)  will  be  readily  detected 
when  I.  is  executed. 


J 


Case  C(6 .2) :  3  =»  A  (I.)  s  K  ,  and  4(1  )  =  2.  The  following 

j  max  K 


procedure  is  followed  in  this  case. 
Procedure  4 .23: 


This  procedure  is  applicable  for  case  C(6.2).  It  generates 

tests  to  detect  fault  f(I./l.+I.  )  when  3  ^  4(1.)  ^  K  ,  and  4(1  )  =  2. 

s  j  j  k  j  max  k 

Step  1:  Store  proper  operands  in  3(1^.)  and  OPERAND  1  in  D(I^)  such 

that  when  1^  is  executed  RESULT  1  is  produced  in  D(I^) ,  and 

OPERAND  1  t  RESULT  1.  If  D(I.)  =  S (I  )  then  store  a  proper 

J  X 

operand  in  S(I^)  such  that  when  1^  is  executed  the  contents  of 
D(I^)  will  not  change.  /To  ensure  that  after  executing  1^, 
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the  contents  of  S(I^)  remain  unchanged/ 

Step  2 :  Execute  I  . 

Step  3:  Read  out  D/I^)  by  executing  READ  (D/I^)). 

/Expected  output  data  =  OPERAND  1/ 

Step  4:  If  £(S(I^))  2  3  then  repeat  steps  2  and  3  else  go  to  step  5. 

Step  5:  Execute  1^. 

Step  6:  Read  out  D(I^)  by  executing  READ  (D(I^)). 

/Expected  output  data  =  RESULT  1/  C 

Theorem  4 .22 :  Procedure  4.23  detects  f(I./l.+I.  )  in 

-  j  j  k 

case  C  (6 .2 ) . 

The  proof  of  this  theorem  is  not  given  as  it  follows  the  same 

arguments  given  in  the  proofs  of  Theorems  4.10  through  4.17. 

Case  C(6 .3) :  K  +  l  *  i(l.)  s  K  .  ,  1(1,)  =  K  2  3.  Therefore 
- 1 - u  j  max  k 

according  to  the  assumption  in  Section  4.3.1,  instructions  I.  and  I 

J 

belong  to  class  T.  In  this  case  the  procedure  given  below  is  followed. 
Procedure  4.24: 

This  procedure  is  applicable  for  case  C(6.3).  It  generates 

tests  to  detect  fault  f(I./I.+I,  )  when  K  +  l  s  l  (T  )  s  K  ,  1(1.  )  =  K, 

J  J  k  k  max  k 

and  K  2  3. 

Step  1:  Store  OPERAND  1  in  S (1^)  and  OPERAND  2  in  D(Ik>  such  that 

OPERAND  1  t  OPERAND  2.  If  D(I . )  =  S (I,  )  then  store  OPERAND  1 

j  k 

in  S(Ij).  /To  ensure  that  after  executing  1^,  the  contents 
of  S/I^)  remain  unchanged/ 

Step  2 ;  Execute  I  . 


/Expected  output  data  ■  OPERAND  2 .  S/I^)  would  continue  to 

store  its  data  after  executing  READ  (D(I^))>  since 
*<S(Ik))  s  K/ 

Step  4:  Execute  I ^ ■ 

Step  5:  Read  out  0(1^)  by  executing  READ  (D(I^)) 

/Expected  output  data  =  OPERAND  1/  □ 

Theorem  4.23:  Procedure  4.24  detects  f(I./I.+I,  )  in 

-  j  j  k' 

case  C (6 .3) -  □ 

The  proof  of  this  theorem  is  not  given  as  it  follows  the  same 
arguments  used  in  the  proofs  of  Theorems  4.10  through  4.17. 


4.4.  Test  Generation  Procedures  for  Detecting  Faults  in  the  Data  Transfer 
Function  and  the  Data  Storage  Function 

We  motivate  the  discussion  by  means  of  an  example.  Let 

I .  ,  I I .  be  a  sequence  of  instructions  of  class  T  such  that 
J1  J2  Jk 

E(I.  ),  E(I.  ),  ...,  E(I.  )  form  a  directed  path  from  the  IN  node  to  the 
J1  J2  Jk 

OUT  node  in  the  corresponding  S-graph.  Let  the  transfer  paths  in  sets 

T(I .  ),  T(I.  ),  ...,  T(I.  )  each  be  w  lines  in  width.  Figure  4.6 
J1  J2  Jk 

illustrates  the  notation.  We  propose  Procedure  4.25  to  detect  any  fault  in 


T (I .  ),  T (I .  ),  ...,  T (I  ),  and  in  registers  D(I  ),  D(I  ),  ...,  D(I. 


J 


J 


1 


Jk-1}- 


The  fault  models  for  the  data  storage  function  and  data  transfer  function 
are  given  in  Section  3.3  and  3.4,  respectively. 

Procedure  4.25: 

I.  with  data  111...1  ;  /Write  D(I .  )  with  data  111. . . 1 / 


J 


w  width 


'1 


w  width 


Figure  4.6.  Illustrating  the  notation  used  in  Procedure  4.25. 
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i,  ;  i,  ;  •••;  i.  ; 

Jk 


h  j3 


/Expected  output  data  =  111...1/ 

4 - ► 

w  width 


I.  with  data  11... i  00... 0  /Write  D(I.  )  with  data  11... 1  00... 0/ 

J1  4 - p4 - ►  J1  4 - P4 - P 

w/2  w/2  w/2  w/2 


1  ;  1  ;  I  ; 

J2  J3  Jk 


/Expected  output  data  =  11... 1  00... 0/ 

4 - —P  4 - — ► 

w/2  w/2 


I.  with  data  11... 1  00... 0  11... 1  00... 0  ; 

J1  4 - ►  4 - P  -4 - ►  4 - ► 

w/4  w/4  w/4  w/4 

/Write  D(I.  )  with  data  11... 1  00... 0  11... 1  00... 0/ 

31  *~W4*  4W4>  +T7? 

I.  ;  I.  ;  ...;  I.  ;  /Expected  output  data  =  11. ..1  00. ..0  11. ..1  00. ..0/ 


J2  J3 


4 - —*  4 - ►  -4 - ►  4 - ► 

w/4  w/4  w/4  w/4 


I.  with  data  1010... 10;  /Write  D(I.  )  with  data  1010... 10/ 


j- 


w 


w 


I,  5  Ij  ;  •••;  ij  ; 

J2  J3  Jk 


/Expected  output  data  =  1010... 10/ 

4 - ► 


w 


Repeat  the  instructions  above  with  complementary  data.  □ 

Theorem  4 .24 :  Procedure  4.25  detects 
1)  a  line  in  any  transfer  path  in  the  set  T(I  .  )  U  T(I.  )U  ...  UT(I,  ) 


Jr 


stuck  at  0  or  1. 

2)  two  or  more  lines  in  any  transfer  path  in  the  set 
T(I .  )  U  T(I.  )  U  ...  U  T (I .  )  coupled. 


3)  a  cell  of  any  register  in  the  set  D(I.  )  U  D(I.  )  U  . . .  U  D(I .  ) 

J1  h  Jk-1 


stuck  at  0  or  1. 


Proof:  If  a  fault  is  described  by  1  or  3  above,  it  will  be 


detected  either  after  the  execution  of  sequence  I .  ,  I . 


I .  when 
Jk 


the  expected  output  data  =  111...1,  or  after  the  execution  of  the  sequence 
when  the  expected  output  data  =  000... 0. 

Procedure  4.25  also  detects  any  fault  described  by  2,  because 

at  some  stage  of  the  procedure  any  given  two  lines  of  a  transfer  path 

are  required  to  carry  different  logic  values  i.e.,  x  and  x,  x  £  [0,l], 

respectively.  If  these  two  lines  are  coupled  they  will  fail  to  carry 

different  logic  values,  and  the  fault  will  be  detected  after  the  subsequent 

execution  of  the  sequence  I., I.,..., I..  □ 

J2  J3  Jk 

We  define  the  set  of  tests  in  Procedure  4.25  "transfer  test  set" 
and  the  associated  data  being  routed  on  the  corresponding  transfer  paths 
"transfer  test  data".  Consider  the  transfer  paths  associated  with  the 
instructions  of  class  T.  Concentrate  on  the  subgraph  of  the  S -graph 
that  represents  instructions  of  class  T  only.  We  call  this  subgraph  the 
T-subgra ph ■  Let  be  a  directed  path  from  the  IN  node  to  the  OUT  node 
in  the  T-subgraph.  All  the  instructions  which  are  represented  by  edges 
constituting  path  P^  are  said  to  be  covered  by  path  P^ .  Let  [p^,  P^ ,  .  Pfl 
be  a  set  of  directed  paths  from  the  IN  node  to  the  OUT  node  of  the  T-subgraph 
such  that  this  set  collectively  covers  all  the  instructions  of  class  T. 

It  is  clear  from  Theorem  4.24  that  if  the  transfer  test  data  is  routed  from 
the  IN  node  to  the  OUT  node  using  the  transfer  test  sets  consisting  of 
instructions  covered  by  each  path  in  set  { P^,  P^ ,  . ..P^}  anY  fault  in  the 
transfer  paths  associated  with  the  instructions  of  class  T,  or  any  fault 
in  the  data  storage  function  will  be  detected  (since  the  transfer  test 
data  is  "routed"  on  every  edge  of  the  T-subgraph,  every  node  of  the  graph 
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is  also  visited) . 

We  need  to  test  the  transfer  paths  associated  with  the  instruc¬ 
tions  of  class  M.  Let  "R^o  R  -*  R^"  denote  a  typical  instruction  of  class  M 
which  performs  an  operation  denoted  by  "o"  on  the  contents  of  register  R 

and  R.,  and  stores  the  result  in  register  R,  .  We  need  to  choose  a  set  of 
j  K 

proper  operands  in  R^  and  R  such  that  when  the  instruction  "R^o  R.  -  R^" 
is  executed  it  generates  and  stores  data  corresponding  to  the  transfer 
test  set  in  R^.  We  then  need  to  route  these  data  from  R^  to  the  OUT  node 
by  executing  READ  (R^) •  This  test  ensures  that  the  transfer  path  from 
the  data  manipulation  logic  (e.g.  the  ALU  used  in  executing  instruction 
"R^o  Rj  -•  R^")  to  register  R^  is  fault  free.  Therefore  any  result  generated 
by  this  instruction  can  be  faithfully  transferred  to  R^.  Consider  instruc¬ 
tion  1^  in  the  S-graph  of  Figure  2.8.  We  execute  Procedure  4.26  to  test 
the  transfer  path  from  the  ALU  to  R^.  (It  is  assumed  that  the  microprocessor 
is  an  8-bit  processor.) 

Procedure  4.26: 

11  with  data  1111  1111  ; 

1 2  with  data  0000  0000  ; 

*4  ; 

X7  ; 

Repeat  the  tests  above  with  data  (1111  0000,  0000  0000), 

(1100  1100,  0000  0000),  (1010  1010,  0000  0000),  (0000  0000  0000  0000), 

(0000  1111,  0000  0000),  (0011  0011,  0000  0000),  (0101  0101,  0000  0000).  □ 


We  also  need  to  check  that  the  transfer  paths  connecting  R^ 

and  R.  to  the  ALU  in  the  "R.o  R.  —  R.  "  instruction  are  fault  free.  This 
J  l  j  1c 


139 

ensures  that  any  pair  of  operands  can  be  applied  to  the  ALU  in  the 

"R.  o  R.  -*  R. "  instruction.  For  this  we  need  to  check  that  any  line  in  the 
i  j  K.  1 

transfer  paths  from  R^  and  R_.  to  the  ALU  can  be  set  to  0  or  1  independent 
of  the  logic  values  on  any  other  line  in  these  transfer  paths.  Consider 
instruction  1^  in  Figure  2.8.  We  waiit  to  test  the  transfer  paths 
connecting  R^  and  R^  to  the  ALU.  We  execute  Procedure  4.27. 

Procedure  4.27: 

I ^  with  data  0000  0001  ;  /R  stores  0000  0001/ 

I2  with  data  0000  0000  ;  /R  stores  0000  0000/ 

*4  5 

I  -j  ;  /Expected  output  data  0000  0001/ 

1^  with  data  0000  0010  ;  /R^  stores  0000  0010/ 

with  data  0000  0000  ;  /R^  stores  0000  0000/ 

X4  > 

1^  ;  /Expected  output  data  0000  0010/ 


1^  with  data  1000  0000  ; 
I2  with  data  0000  0000  ; 

X4  ; 

X7  ; 

1^  with  data  0000  0000  ; 
I2  with  data  0000  0001  ; 


/R^  stores  1000  0000/ 

/R2  stores  0000  0000/ 

/Expected  output  data  1000  0000/ 
/R^  stores  0000  0000/ 

/R9  stores  0000  0001/ 

/Expected  output  data  0000  0001/ 
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11  with  data  0000  0000  ;  /R  stores  0000  0000/ 

1 2  with  data  0000  0010  ;  /R2  stores  0000  0010/ 

r4  ; 

1^  ;  /Expected  output  data  0000  0010/ 

1^  with  data  0000  0000  ;  /R  stores  0000  0000/ 

I2  with  data  1000  0000  ;  /R  stores  1000  0000/ 

X4  5 

1^  ;  /Expected  output  data  1000  0000/ 

Repeat  the  test  above  with  complementary  data.  □ 

We  need  to  execute  tests  similar  to  those  given  in  Procedures 
4.26  and  4.27  for  every  instruction  of  class  M.  Finally  we  must  test 
the  transfer  paths  associated  with  the  instructions  of  class  B.  This 
is  accomplished  by  choosing  the  set  of  jump  or  branch  addresses  such 
that  they  correspond  to  the  transfer  test  set  for  jump,  branch,  return 
from  subroutine,  etc.,  instructions.  For  example,  in  order  to  test  the 
transfer  path  associated  with  the  jump  instruction  (instruction  Ig) 
in  Figure  2.8  we  need  to  execute  Procedure  4.28.  It  is  assumed  that  the 
width  of  the  address  bus  is  16. 

Procedure  4.28: 

1^  with  jump  address  0000  0000  0000  0000  ; 

Ig  with  jump  address  0000  0000  1111  1111  ; 

Ig  with  jump  address  0000  1111  0000  1111  ; 

Ig  with  jump  address  0011  0011  0011  0011  ; 

Ig  with  jump  address  0101  0101  0101  0101  ; 
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Repeat  the  test  above  with  the  complementary  set  of  jump  addresses. 

4.5.  Test  Generation  Procedure  for  Detecting  Faults  in  the  Data 
Manipulation  Function 

As  described  in  Section  3.5  we  assume  that  complete  test  sets 
are  available  for  detecting  faults  (for  some  specified  fault  model) 
in  the  ALU  and  other  functional  units  such  as  a  shifter,  logic  used  to 
increment  the  program  counter,  or  the  interrupt  handling  logic.  The 
operands  specified  by  such  test  sets  can  be  provided  to  a  functional 
unit  using,  in  general,  a  sequence  of  instructions  of  class  T. 

Similarly,  the  result  produced  by  a  functional  unit  can  be  read  out  using 
a  sequence  of  instructions  of  class  T. 

If  the  logic  level  description  of  functional  units  is  available, 
test  sets  can  be  generated  for  them  using  classical  fault  detection 
algorithms  based  on  the  stuck-at  fault  model.  On  the  other  hand,  if  we 
do  not  know  the  logic  level  details  of  the  ALU,  but  know,  for  example, 
that  it  is  realized  using  an  iterative  logic  array  we  can  generate  test 
sets  for  it  as  explained  in  [Dias76]  ■  Another  approach  would  be  to 
generate  test  sets  for  functional  testing  of  the  ALU,  shift,  increment, 
compare  logic,  etc.,  using  binary  decision  diagrams  [Aker78] . 

Even  though  some  faults  associated  with  the  instruction 
decoding  and  control  function  look  like  faults  in  the  data  manipulation 
function,  and  vice  versa,  the  set  of  faults  in  one  function  is  not  a  subset 
or  superset  of  the  set  of  faults  in  the  other  function.  For  example, 
under  a  fault  in  the  instruction  decoding  function  an  "Add"  instruction 
may  be  decoded  as  a  "Subtract"  instruction.  This  fault  cannot  be 
distinguished  from  a  fault  in  the  ALU:  however,  if  the  test  procedure 


for  detecting  faults  in  the  instruction  decoding  and  control  function 
(presented  in  Section  4.3)  is  executed  correctly,  it  cannot  guarantee  the 
absence  of  faults  in  the  ALU-  In  order  to  detect  a  fault  in  the  ALU 
or  any  other  functional  units  we  need  to  execute  the  corresponding  test 
sets.  Similarly  if  the  test  procedure  for  detecting  faults  in  the 
data  manipulation  function  is  executed  correctly,  it  does  not  guarantee 
the  absence  of  faults  in  the  instruction  decoding  and  control  function. 

For  example,  whenever  an  "Add"  instruction  is  executed,  it  may 
additionally  activate  an  instruction  that  complements  a  certain  register 
not  involved  in  the  "Add"  instruction.  Such  a  fault  can  be  detected  by  the 
test  procedure  used  to  detect  faults  in  the  instruction  decoding  and 
control  function  and  not  by  the  test  procedure  used  to  detect  faults  in 
the  data  manipulation  function. 
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5.  COMPLEXITY  OF  THE  TEST  SEQUENCES 

We  now  determine  the  complexity  of  the  test  sequences  generated 
by  various  procedures  given  in  Chapter  4.  The  complexity  is  measured 
in  terms  of  the  number  of  instructions  generated  as  a  function  of  n_-  the 
number  of  registers  in  set  ft,  or  n^.-  the  number  of  instructions  in  the 
instruction  repertoire.  This  will  help  in  exploring  the  relationship 
between  the  architecture  of  a  microprocessor  and  the  complexity  of  the 
test  sequences . 

Theorem  5.1:  The  worst  case  complexity  of  the  test  sequence 
generated  by  Procedure  4.1  is  0(n^),  where  |ft|  =  n^. 

Proof :  Let  us  consider  the  number  of  instructions  that  are 
generated  in  steps  3(a),  (b),  and  (c)  of  Procedure  4.1  when  there  are  K 
registers  in  set  A,  i.e.,  |a|  *  K.  As  a  result  of  the  labeling  algorithm, 
max(£ (R^) )  =  K'  s  K  for  every  register  of  set  A.  Also,  every  number  in  the 
integer  set  fl,2,  ...,  K'}  is  assigned  as  a  label  to  at  least  one  register 
in  set  A.  Therefore,  in  the  worst  case,  during  step  3(b)  we  need  to 
generate  £(1  +2  +  ...  +  K)  instructions  which  would  read  out  the  registers 


of  set  A,  where  I A [  =  K.  Since  set  A  is  augmented  only  by  one  register 
during  each  iteration  of  step  3,  in  the  worst  case,  H^l  Z(1 


+2  +  ...  +  K) 


instructions  need  to  be  performed  for  reading  out  registers  of  set  A. 

tv1 

Similarly,  in  all  iterations  of  step  3(c),  a  total  of  l  (K  +  1)  instruc¬ 
ts  1 

tions  need  to  be  generated  to  read  out  the  register  at  the  front  of  the 
queue . 

Since  there  are  only  n  registers,  the  register  that  is 

R 

"farthest  away"  from  the  IN  node  can  be  written  by  executing  at  most  n^, 

instructions  of  class  T.  Moreover,  if  this  register  needs  n  instructions 

R 
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to  be  written  into,  the  "next  farthest  away"  register  will  require  (n  -1) 

R 

instructions,  and  so  on.  Therefore  when  | A 1  =  K,  in  the  worst  case, 

n  -  (K  -  1)  +  n  -  (K  -  2)  +  (n  -  1)  +  n  instructions  are  required  to  write 
R  R  R  R 

the  registers  of  a  set  A  during  step  3(a).  During  all  iterations  of 

V1 

step  3(a) ,  a  total  of  £  2  n  -(K  -  1)  +  n  -(K  -  2)  +  ...  +  n 

K=1  R  R  R 

instructions  are  needed  to  write  the  registers  of  set  A.  Similarly  in 

nR~  1 

all  iterations  of  step  3(a),  a  total  of  2  (n  -  K)  instructions  are 

r  k=1  R 

needed  to  write  the  register  at  the  front  of  the  queue,  in  the  worst  case. 

When  all  the  terms  involved  in  series  are  summed  up,  a  total  of 
3  '2 

n^  +  2n^  -  n^  -  2  instructions  are  generated.  Hence  the  worst  case 

3  „ 

complexity  of  the  test  sequence  is  <J(n  ) .  P 

R  ’ 

It  is  instructive  to  illustrate  the  worst  case  example  which 

is  shown  by  a  partial  S-graph  in  Figure  5.1.  Note  that  ^(n^)  complexity 

is  only  for  the  worst  case.  For  n^  =  7,  432  instructions  are  generated 

in  the  worst  case.  However,  for  the  example  microprocessor  (where  n^  =  7) 

only  2  x  53  =  106  instructions  are  generated  as  shown  in  Example  4.2. 

The  exact  number  of  instructions  depends  on  the  distribution  of  integer 

labels  of  the  nodes.  In  fact,  if  all  nodes  have  label  1  (i.e.,  if  the 

architecture  contains  only  the  so-called  accumulators  and  general  purpose 

registers  which  can  be  directly  loaded  into  and  stored  from  the  main 

memory),  the  complexity  of  the  test  sequence  would  be  ^(n  )•  On  the 

R 

other  hand,  if  the  architecture  allows  scratch-pad  registers  and  on-chip 

LIFO  stacks,  for  example,  (giving  rise  to  nodes  with  labels  greater 

than  1  in  the  S-graph),  the  complexity  of  the  test  sequence  approaches  ^(n^) . 

It  is  very  difficult  to  find  a  closed  form  solution  for  the 
worst  case  complexity  of  the  test  sequence  generated  by  procedures  in 


Section  4.3.  We  will  therefore  concentrate  on  the  dominating  term  in  the 

worst  case  complexity  calculation.  This  dominating  term  can  be  attributed  to 

the  loop  in  ,'tep  2  of  Procedures  4.10,  4.20  and  4.22.  Let  ru.  be  the  number 

i 

of  instructions  whose  edge  sets  have  been  labeled  i  in  the  S-graph.  As 

denoted  earlier,  let  K  be  the  maximum  value  of  labels  associated  with  the 

W  maX  Kmax  i 

edge  sets.  Thus  L  nT  =  n_ .  The  dominating  term  accounts  for  £  n_  (i  ) 
i=l  Li  l  i=l 

instructions  generated  by  step  2  of  Procedures  4.10,  4.20  and  4.22. 

If  the  architecture  allows  instructions  which  are  represented 

by  edge  sets  with  labels  much  greater  than  1,  the  length  of  the  test 

sequence  could  become  very  large  in  the  worst  case,  since  the  complexity 

grows  exponentially  (note  the  i1  factor  in  the  expression  above) .  This  is 

because  instructions  represented  by  edge  sets  with  large  labels  impart 

very  poor  observability  to  the  architecture,  i.e.,  a  large  number  of 

instructions  need  to  be  executed  to  read  out  internal  registers;  this  is 

reflected  in  the  increased  length  of  the  test  sequences  generated  by 

procedures  in  Section  4.3.  However,  the  expression  above  is  applicable 

only  in  the  worst  case;  in  many  typical  architectures  Kmax  5  3,  deemphasizing 

the  effect  of  the  dominating  term.  In  fact,  if  K  ^2  (i.e.,  the  instruction 

repertoire  contains  instructions  that  store  their  result  in  the  main  memory 

or  the  accumulators  and  general-purpose  registers),  Procedures  4.10,  4.20 

and  4.22  will  not  be  required  at  all.  In  the  case  of  such  architectures, 

the  complexity  of  the  test  sequences  generated  by  the  procedures  given  in 

2  2 

Section  4.3  can  be  approximated  to  ^(n^)  because  there  are  (3-(n  )  faults 
(in  the  instruction  decoding  and  control  function)  and  none  of  them  will 
require  Procedure  4.10,  4.20  or  4.22  to  generate  tests  for  it.  Note  that  no 
.other  procedure  has  a  loop  similar  to  that  in  step  2  of  Procedures  4.10,  4.20 
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and  4.22.  Therefore  Che  complexity  of  test  sequences  generated  by  these 

2 

procedures  can  be  approximated  to  ^(n^.)- 

The  length  of  the  test  sequence  generated  by  various  procedures 


given  in  Section  4.4  depends  on  the  widths  of  data  and  address  buses, 
the  nature  of  operation  "o"  performed  by  instructions  "R^o  R  —  R^"  of 
class  M,  and  the  distribution  of  integer  labels  associated  with  edge 


sets,  i.e.,  il.  and  K  •  If  there  are  many  instructions  with  higher 
X  .  HlHX 

1 

labels  (i.e.,  large  n^  for  larger  i) ,  the  length  of  the  test  sequences 

i 

required  to  detect  a  fault  in  the  data  transfer  and  data  storage  functions 


increases . 


For  today's  microprocessors  n  typically  ranges  from  4  to  32, 

R 

while  Oj.  ranges  from  30  to  200.  Note  that  the  complexity  of  the  test 

sequences  for  detecting  faults  in  the  instruction  decoding  and  control 

2 

function  is  at  least  ^(n^) ,  while  the  complexity  of  the  test  sequences 
for  detecting  faults  in  the  register  decoding  function  is  between 


O(n^)  and  ^(n^) ■ 


Therefore  the  test  sequences  used  to  detect  faults  in 


the  instruction  decoding  and  control  function  constitute  a  dominant  portion 
of  the  test  sequences  for  a  microprocessor. 
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6.  A  CASE  STUDY 

Test  sequences  were  generated  for  a  real  microprocessor  by  applying 
the  test  generation  procedures  developed  in  the  thesis.  The  goal  of  the  study 
was  two-fold.  First,  we  wanted  to  generate  the  test  sequences  to  gain  insight 
into  problems  involved  in  using  the  test  generation  procedures.  We  believe  that 
this  is  an  essential  first  step  towards  automating  the  test  generation  procedures 
which  will  operate  on  a  given  S-graph.  Secondly,  we  wanted  to  evaluate  the  fault 
coverage  of  the  test  sequences  for  stuck-at  faults  for  a  real  microprocessor. 

A  microprocessor  from  the  Hewlett-Packard  Company  was  used.  The 
HP  microprocessor  is  a  single  chip,  n-channel  MOS,  8  bit  parallel,  control 
oriented  processor.  All  instructions  and  data  are  transferred  in  and  out 
of  the  microprocessor  with  an  8  bit  bidirectional  data  bus.  Program 
addresses  are  transferred  out  on  an  11  bit  address  bus.  There  can  be  up  to 
15  I/O  ports.  The  normal  program  may  be  interrupted  by  use  of  the 
interrupt  request  control  line.  The  interrupt  scheme  is  fully  vectored 
with  256  possible  vectors.  The  processor  can  control  external  circuits 
and  check  their  status  through  the  use  of  7  bidirectional  control  lines. 

The  microprocessor  contains  one  8  bit  accumulator,  one  control 
logic  unit,  one  1  bit  extend  register,  sixteen  8  bit  registers,  one  8  bit 
magnitude  comparator,  one  11  bit  program  counter,  one  11  bit  subroutine 
stack  register,  and  one  11  bit  interrupt  stack  register.  The  instruction 
set  has  187  instructions  that  includes  instructions  transferring  data 
between  the  memory  and  the  accumulator,  between  the  memory  and  (sixteen 
8  bit)  registers,  between  the  accumulator  and  registers,  between  the 
accumulator  and  I/O  devices,  instructions  performing  bit  manipulations  and 
magnitude  comparisons,  instructions  performing  conditional  and  unconditional 


jumps  in  the  program  sequencing,  etc. 
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We  adopted  the  following  strategy  in  applying  the  test  sequences. 
Since,  as  shown  in  Chapter  5,  the  test  sequences  for  the  instruction 
decoding  and  control  function  form  the  dominant  portion  of  the  test  sequences 
for  the  microprocessor,  we  first  applied  the  test  sequences  for  the  register 
decoding  function,  the  data  transfer  and  the  data  storage  function,  and 
the  data  manipulation  function.  The  length  of  these  sequences  was  approx¬ 
imately  1  K  instructions.  This  was  followed  by  application  of  the  test 
sequences  for  the  instruction  decoding  and  control  function.  The  length 
of  these  sequences  was  approximately  8  K  instructions.  (Recall  that  there 
are  187  instructions  in  the  instruction  repertoire.)  The  test  sequences 
were  generated  by  using  only  the  information  about  the  instruction  set  and 
organization  of  the  microprocessor. 

In  order  to  determine  the  fault  coverage  of  the  test  sequences 
for  stuck-at  faults,  a  detailed  gate  and  subnetwork  model  of  the  micro¬ 
processor  (obtained  from  Hewlett-Packard)  was  used  on  the  TESTAID  III  fault 
simulator.  Approximately  2200  single  stuck-at  faults  were  simulated.  The 
test  sequences  generated  were  run  in  segments  (since  the  simulator  could 
not  handle  all  the  tests  at  one  time)  and  the  fault  coverage  of  each 
segment  was  noted.  The  test  sequences  for  the  register  decoding,  data 
storage,  data  transfer,  and  data  manipulation  functions  were  able  to  detect 
about  90%  of  all  single  stuck-at  faults.  About  6%,  of  the  faults  gave  rise 
to  simultaneous  execution  of  multiple  instructions  as  described  by  the 
fault  model  for  the  instruction  decoding  and  control  function.  Many  of 
these  faults  were  subtle  and  difficult  to  detect  and  very  elaborate  test 
sequences  were  required  (accounting  for  8  K  instructions).  For  example, 
when  executing  the  instruction  "Skip  if  the  nt'1  bit  of  the  accumulator  is  0" 
(with  n  between  0  and  7),  under  a  particular  single-at  fault,  the  above 


150 


instruction  will  be  executed  correctly,  but  at  the  same  time,  the  contents 
of  the  accumulator  are  also  stored  in  the  n^  register.  Some  examples 
of  f(I-/l.+I .  )  faults  found  in  the  case  study  are  given  in  Table  6.1. 

J  J  iC 

(the  table  lists  instructions  I.  and  I,  . ) 

J  k 

The  remaining  faults  (about  47.)  were  associated  with  the  power-up 
and  initialization  logic,  or  were  undetectable  because  of  redundancies 
in  the  logic,  or  required  invalid  opcodes  to  detect  them.  Thus  for  this 
particular  microprocessor  the  fault  coverage  was  excellent. 

The  test  generation  effort  was  quite  straightforward  and  we 
believe  that  it  can  be  automated  without  much  difficulty.  The  overall 
results  of  the  case  study  were  quite  promising  and  we  are  convinced  that 
our  approach  is  a  viable  and  effective  one  for  generating  tests  for  micro¬ 


processors  . 


Table  6.1.  Instructions  I.  and  I,  for  which  fault  f(I./I.+I,)  exists. 

i  k  i  l  k 


Instruction  1^ 

Instruction  I, 
k 

Clear  the  extend  bit. 

Transfer  the  contents  of  the  accumulator 
to  register  . 

Return  from  interrupt 
and  enable  interrupt. 

Transfer  the  contents  of  the  accumulator 
to  register  R^ . 

Clear  the  third  control 
flag. 

Disable  interrupt. 

Skip  if  the  first 
control  flag  is  zero. 

Enable  interrupt. 

Clear  the  first  bit  of 
the  accumulator. 

Clear  the  zeroth  bit  of  the  accumulator. 
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7.  CONCLUDING  REMARKS 

7.1.  Summary  of  Thesis 

The  purpose  of  this  research  has  been  to  develop  test  generation 
procedures  for  testing  microprocessors  that  would  treat  the  microprocessor 
organization  and  instruction  set  as  parameters.  The  test  generation 
effort  is  assumed  to  be  in  a  user  environment  where  the  gate  and  flip-flop 
level  details  of  the  microprocessor  are  not  known.  The  procedures  will 
generate  tests  which  can  be  assembled  into  valid  machine  instructions. 

The  microprocessor  under  test  executes  these  instructions  which  are  stored 
in  the  memory  of  an  external  tester  which  continually  monitors  all  the 
input  and  output  pins  of  the  microprocessor.  A  fault  is  detected  when  the 
data  on  any  output  pin  is  different  from  the  expected  data. 

In  Chapter  2,  -he  instruction  repertoire  of  the  microprocessor 
was  divided  into  three  classes  (T,  M,  and  B) .  Then  a  graph-theoretic 
model  for  microprocessor  (called  the  S-graph)  was  developed.  Each  register 
is  represented  by  a  node  in  the  S-graph  and  data  flow  involved  during  the 
execution  of  an  instruction  is  represented  by  a  set  of  directed  edges. 

The  motivation  behind  this  approach  was  to  be  able  to  construct  a  model 
for  the  microprocessor  for  test  generation  purposes  using  only  the  informa¬ 
tion  available  in  the  typical  user's  manual.  This  is  because  the  gate  and 
flip-flop  level  information  needed  to  construct  a  model  at  the  logic  level 
is  not  only  unavailable,  but  classical  test  generation  methods  which  go 
hand  in  hand  with  the  logic  level  model  will  be  very  complicated  and 
expensive  due  to  the  very  large  number  of  gates  and  flip-flops  on  the 
microprocessor  chip. 

Functional  level  fault  models  describing  faulty  behavior  in  the 
register  decoding  function,  instruction  decoding  and  control  function,  data 
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transfer  function,  and  data  manipulation  function  were  presented  in  Chapter  3. 
Various  underlying  fault  mechanisms  responsible  for  functional  level  faults 
were  pointed  out.  The  fault  models  are  quite  independent  of  the  details 
of  implementation.  The  effects  of  faults  on  the  behavior  of  the  micro¬ 
processor  were  described  at  the  level  of  the  S-graph. 

In  Chapter  4,  test  generation  procedures  were  given  to  detect 
faults  in  the  fault  models.  The  first  step  in  test  generation  is  to 
assign  integer  labels  to  the  nodes  and  edges  of  the  S-graph  by  using  the 
labeling  algorithm  given  in  Section  4.1.  The  label  assigned  to  a  node 
indicates  the  shortest  "distance"  of  that  node  to  the  OUT  node  (in  terms 
of  the  instructions  of  class  T  or  B) ;  the  label  assigned  to  the  edge  set 
representing  an  instruction  is  directly  derived  from  the  label  assigned  to 
its  destination  register. 

Test  generation  procedures  presented  in  the  subsequent  sections 

of  the  chapter  take  full  advantage  of  the  information  obtained  from  these 

labels;  tests  are  generated  in  such  a  way  that  the  knowledge  gained  from 

the  correct  execution  of  tests  used  for  checking  the  decoding  of  registers 

and  instructions  with  lower  labels  is  utilized  in  generating  tests  for 

checking  the  decoding  of  registers  and  instructions  with  higher  labels. 

In  Chapter  5,  the  complexity  of  test  sequences  generated  by  the 

test  generation  procedures  in  Chapter  4  was  studied.  The  complexity  is 

measured  in  terms  of  the  number  of  instructions  generated  as  a  function  of 

n  -  the  number  of  instructions  in  the  instruction  repertoire.  The  worst 
R 

case  complexity  of  the  test  sequence  for  the  register  decoding  function 

3 

was  shown  to  be  £>(n  ) ;  however,  if  all  registers  have  label  1  (indicating 
R 

o 

the  highest  observability)  the  complexity  would  be  2(n^). 

K 


It  was  shown  that  if  the  instructions  have  labels  less  than  or 


equal  to  two,  the  complexity  of  test  sequences  for  the  instruction  decoding 
and  control  function  is  ^(n^) .  If  the  architecture  allows  instructions 
with  labels  greater  than  two,  the  complexity  increases  very  rapidly. 

typically  ranges  from  4  to  32,  while  n^  ranges  from  30  to  200, 
the  test  sequences  for  the  instruction  decoding  and  control  function 
constitute  a  dominant  part  of  the  test  sequences  of  a  microprocessor. 

In  Chapter  6  we  have  described  our  effort  regarding  the  develop¬ 
ment  of  test  sequences  based  on  the  test  generation  procedures  in  Chapter  4 
for  a  real  8-bit  microprocessor  from  the  Hewlett-Packard  Company. 
Approximately  2200  single  stuck-at  faults  were  simulated.  About  96%  of 
these  faults  were  detected  by  these  test  sequences.  The  remaining  faults 
were  associated  with  the  power-up  and  initialization  logic,  or  were 
undetectable  because  of  redundancies  in  the  logic  or  they  required  invalid 
opcodes  for  their  detection.  The  results  of  our  study  were  quite  promising. 

Thus  to  summarize  the  thesis,  our  approach  allows  us  to  treat 
the  organization  and  instruction  set  of  microprocessors  as  parameters  of 
the  test  generation  procedures  .  The  information  needed  to  construct  the 
S-graph  is  easily  available  in  the  user's  manual.  We  believe  our  approach 
is  a  viable  and  effective  one  towards  generating  test  sequences  for  micro¬ 
processors  . 

7.2.  Suggested  Future  Research 

The  S-graph  of  the  microprocessor  is  capable  of  modeling  most  of 
the  architectural  features  observed  with  current  microprocessors.  However, 
it  cannot  model  some  of  the  features  observed  in  the  new,  powerful  16 -bit 
microprocessors.  For  example,  instructions  exchanging  data  among  two 


Since 


°R 
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register  files  cannot  be  adequately  modeled.  In  order  to  under¬ 
stand  the  effects  of  these  architectural  features  on  test  generation, 
further  research  needs  to  be  done  to  model  these  architectural  features 
using  the  S-graph  or  some  other  similar  technique. 

Fault  model  for  the  instruction  decoding  and  control  function 

considers  only  "gross"  faults  f(I  ./$),  f(I./l.)»  and  f(I./I.+I  ).  Our 

J  J  k  j  J  k 

case  study  regarding  the  test  generation  for  the  Hewlett-Packard  micro¬ 
processor  and  the  subsequent  evaluation  of  the  fault  coverage  showed  that 
this  fault  model  was  adequate  to  account  for  all  single  stuck-at  faults 
in  the  instruction  decoding  and  control  function  of  this  particular  micro¬ 
processor.  We  do  not  know  how  adequate  the  fault  model  would  be  for  other 
microprocessors,  particularly  the  new  16-bit  microprocessors.  (Some  of 
them  have  an  on-chip  microprogrammed  control  unit.)  Further  research  needs 
to  be  directed  towards  evaluating  the  necessity  of  modeling  other  faults 
such  as  the  ones  that  give  rise  to  partial  execution  of  an  instruction, 
or  a  change  in  the  sequence  of  data  flow  involved  in  an  instruction. 
Furthermore,  if  the  evaluation  study  points  to  the  necessity  of  the  improved 
fault  models,  the  next  problem  will  be  to  describe  the  effects  of  these 
faults  at  the  level  of  the  S-graph  and  then  develop  test  generation  proce¬ 
dures  to  detect  these  faults. 

Another  important  area  of  future  research  is  to  study  the  appli¬ 
cability  of  the  test  sequences  generated  by  the  procedures  of  Chapter  4  in 
a  testing  environment  where  the  sophisticated  tester  required  by  our 
approach  cannot  be  used.  For  example,  in  field  testing,  the  external 
tester  must  be  very  simple  and  most  of  the  testing  tasks  (such  as  comparing 
the  output  result  on  a  bus  with  the  expected  result)  must  themselves  be 
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carried  out  by  the  microprocessor  under  test.  Future  research  must  be 
directed  towards  investigating  the  modifications  to  the  proposed  test 
generation  procedures  to  make  them  suitable  for  field  testing,  or  for  the 
so-called  "se If -testing"  operations.  Self -testing  involves  some  hardcore, 
i.e.,  that  part  of  hardware  which  must  be  assumed  to  be  fault  free. 
Therefore  identification  of  the  hardcore  and  its  testing  by  an  external 
tester  are  two  major  problems  that  need  to  be  solved  for  any  self-testing 
scheme . 

Finally,  future  research  needs  to  be  directed  towards  the 
challenging  problem  of  design  for  testability.  Architectural  features 
which  enhance  testability  should  be  investigated.  Allowing  registers  and 
instructions  with  as  low  labels  as  possible  (imparting  high  observability) 
is  obviously  a  step  in  the  right  direction.  Such  a  solution  might  degrade 
the  performance  of  the  microprocessor  in  yet  unknown  way.  The  underlying 
testability-performance  trade-offs  should  also  be  investigated. 
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APPENDIX 


We  consider  the  behavior  of  a  decoder  (for  a  given  valid  input) 
under  a  single  stuck-at  fault.  The  decoder  is  assumed  to  be  realized 
without  any  reconvergent  fanout.  This  assumption  is  quite  reasonable  as 
a  decoder  has  n  inputs  and  as  many  as  2n  outputs.  No  other  restriction 
is  imposed  on  its  implementation. 

Figure  A.l  shows  a  schematic  diagram  of  a  decoder  which  has  k 
primary  inputs  labeled  x^,  ^  >  •••>  and  n  primary  outputs  labeled 

*  k 

c^,  c^ ,  c  ,  where  n  <  2  .  The  set  of  valid  input  vectors  is  a  subset 

of  the  set  of  all  possible  input  vectors.  Therefore,  the  set  of  valid 

k 

input  vectors  contains  n  ^  2  input  vectors.  The  set  of  valid  input 

vectors  which  activate  output  c^  is  denoted  by  X(c^) .  Since  for  any 

given  valid  input  vector  one  and  only  one  output  is  activated  |x(c  )|  =  1 

and  X(c.)  H  X(c.)  =  d  if  and  only  if  c.  £  c.. 
i  J  i  J 

Figure  A.l  also  shows  the  last  level  of  gates  just  before  the 
primary  outputs.  In  order  to  maintain  complete  generality,  each  gate 
is  shown  as  a  module  and  not  as  a  specific  gate  (such  as  AND,  OR,  NOR  or 
NAND) .  These  gates  are  labeled  with  the  corresponding  outputs,  c^ 
becomes  active  if  and  only  if  all  inputs  to  gate  c^  are  active.  (For  AND 
and  NAND  gates,  logic  1  is  an  active  input;  while  for  OR  and  NOR  gates, 


logic  0  is  an  active  input.)  If  the  output  of  gate  c^  is  active,  the 

output  of  gate  c.  must  be  inactive  (c.  #  c.).  Thus  when  c.  is  active, 
j  l  j  l 

at  least  one  input  of  gate  c.  must  remain  inactive  to  ensure  that  c.  is 

J  J. 

inactive.  We  can  partition  the  inputs  of  gate  c^  into  two  sets,  A(c^) 
and  I(Cj),  where  A(c^)  is  the  set  of  inputs  of  gate  c^  which  are  active 
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when  output  is  active,  and  I(c^)  is  the  set  of  inputs  of  gate  which 

are  inactive  when  output  c^  is  active.  Note  that  I(c^)  ft-  We  now 

prove  Theorem  3.1  which  is  restated  below  for  easy  reference. 

Theorem  3.1:  If  a  decoder  is  realized  without  any  reconvergent 

fanout  then  under  a  single  stuck-at  fault  its  behavior  can  be  formulated 

independent  of  its  implementation  detail  as  follows:  for  a  given  valid 

input  to  the  decoder,  instead  of,  or  in  addition  to  the  expected  output 

some  other  output  is  activated,  or  no  output  is  activated. 

Proof :  We  prove  the  theorem  by  contradiction.  Assume  that 

under  a  single  stuck-at  fault,  the  input  vector  X(c^)  activates  outputs 

c.  and  c.  ,  in  addition  to,  or  instead  of  c. .  Therefore  under  the  fault, 
j  k’  i 

both  I(ci)  and  I(cf)  become  active  in  addition  to  A(c^)  and  A(c,i).  Since 
j  k  j  k 

there  is  only  a  single  fault,  the~inputs  in  XCc3:)  and  I(c£)  can  be  traced 

J  k 

back  to  a  line  where  the  fault  occurs.  This  line  is  denoted  by  f  in 
Figure  A.l.  (This  could  be  a  primary  input  line.)  Since  the  decoder  does 
not  have  any  reconvergent  fanout,  |l(cL)|  =  1  and  [l(c^)|  =  1;  moreover, 
the  primary  inputs  which  can  be  traced  back  from  the  inputs  in  A(c^)  are 
different  from  those  which  can  be  traced  back  from  line  f.  Similarly,  the 
primary  inputs  which  can  be  traced  back  from  the  inputs  in  A(c^)  are 
different  from  chose  which  can  be  traced  back  from  line  f.  Thus,  if  there 
is  no  fault  in  the  decoder,  the  logic  value  on  line  f  can  be  controlled  by 
changing  the  logic  values  only  on  those  primary  inputs  which  can  be  traced 
back  from  line  f,  without  changing  the  logic  values  on  inputs  in  A(c^)  and 
A(c^). 

We  now  consider  the  following  "thought  experiment"  under  the 


fault  free  condition. 
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1.  Apply  X(c^).  This  will  also  activate  the  inputs  in  A(c^)  and 

A  (4). 

2.  If  necessary,  change  the  logic  value  on  those  primary  inputs 

which  can  be  traced  back  from  line  f  in  order  to  activate  line  f,  without 

making  the  inputs  in  A(c1)  or  A(c^)  inactive. 

J  K 

This  will  make  both  iCc1)  and  I(c^)  active  which  means  that  both 

J  k 

c.  and  c,  will  become  active.  Thus  even  though  there  is  no  fault  in  the 
J  k 

decoder,  some  valid  input  vector  activates  both  c  and  c^,  which  is 
impossible.  O 

Theorem  A ■ 1 :  If  a  decoder  is  realized  without  any  reconvergent 
fanout  then  under  a  single  stuck-at  fault  if  X(c.)  activates  c.  instead  of, 

1  j 

or  in  addition  to  c.,  X(c.)  will  activate  only  c.. 

1  J  J 

Proof :  We  prove  this  theorem  also  by  contradiction. 

1)  First  assume  that  under  a  single  stuck-at  fault  X(c^)  activates 

Cj ,  instead  of,  or  in  addition  to  c^,  and  X(c^)  does  not  activate  any 

output.  Therefore  the  inputs  in  I(cJ)  can  be  traced  back  to  a  line  where 

the  fault  occurs.  This  line  is  denoted  by  f  in  Figure  A. 2.  Since  the 

decoder  does  not  have  any  reconvergent  fanout,  Jl(c  )|  =  1,  and  no  input 

in  Ale1)  can  be  traced  back  to  line  f.  When  X(c.)  is  apoiied  no  output 
y  J  J 

is  activated;  in  particular  c^  is  not  activated.  This  can  happen  only  if 
some  input  in  A(cJ)  can  be  traced  back  to  another  fault  which  keeps  that 
input  permanently  inactive;  but  this  would  violate  the  assumption  of  a 
single  stuck-at  fault. 

2)  Now  assume  that  under  a  single  stuck-at  fault  X(c^)  activates  c^ , 
instead  of,  or  in  addition  to  c.,  and  X(c.)  activates  c  ,  instead  of,  or 

1  J  K 

in  addition  to  c . .  Therefore,  the  inputs  in  I(cL)  and  I(c^)  can  be 
J  J  k 
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traced  back  to  a  line  where  the  fault  occurs.  This  line  is  denoted  by  f 

in  Figure  A. 3.  Since  the  decoder  does  not  have  any  reconvergent  fanout, 

iKc1)!  =  1  and  |l(cj)|  *  1;  moreover,  the  primary  inputs  which  can  be 

traced  back  from  the  inputs  in  A(c^)  are  different  from  those  which  can 

be  traced  back  from  line  f.  Similarly,  the  primary  inputs  which  can  be 

traced  back  from  the  inputs  in  A(Cj^)  are  different  from  those  which  can 

traced  back  from  line  f.  Thus  the  logic  value  on  line  f  can  be  controlled 

by  changing  the  logic  values  only  on  those  primary  inputs  which  can  be 

traced  back  from  line  f,  without  changing  the  logic  values  on  inputs  in 

ACc1)  and  A(c.^)  . 
v  j  k 

We  now  consider  the  following  "thought  experiment"  when  there  is 
a  fault  on  line  f  as  shown  in  Figure  A. 3. 

1.  Apply  X(c^) .  This  will  also  activate  the  inputs  in  A(c^).  Due  to 

the  fault  on  line  f,  the  input  in  I(c^)  also  becomes  active,  consequently 

activating  c..  At  this  time  some  input(s)  in  A(c^)  must  be  inactive 
J  k 

because  c,  is  not  active, 
k 

2.  Change  the  logic  value  on  those  primary  inputs  which  can  be 

traced  back  from  line  f  in  order  to  activate  line  f  (for  this  X(c.)  needs 

J 

to  be  applied),  without  changing  the  logic  values  in  A(cL)  and  A(c,J),  i.e., 

J  K 

the  inputs  in  A(cX)  are  active  and  some  input(s)  in  A(c^)  are  inactive. 

J  K 

Thus  we  get  in  a  situation  where  X(c.)  does  not  activate  c, 

j  k 

even  though  fault  on  line  f  exists,  contradicting  our  assumption. 


□ 


Corollar ly  A . 1 :  If  a  decoder  is  realized  without  any  reconver¬ 
gent  fanout  then  under  a  single  stuck-at  fault  if  X(c^)  does  not 

activate  any  output,  or  activates  c,  ,  instead  of,  or  in  addition  to  c , , 

*  J 

no  X(c  )  will  activate  c.,  instead  of,  or  in  addition  to  c  ,  for  c  ^  c.. 

q  j  q  q  j 


Figure  A. 3.  Schematic  diagram  of  a  decoder  illustrating  the 
notation  used  in  the  second  part  of  the  proof  of 
Theorem  A . 1 . 
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Proof :  Follows  directly  from  Theorem  A.l.  Q 

Constraints  4  and  5  given  in  Section  3.2  are  consistent  with 
Theorem  A.l  and  Corollary  A.l. 
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